shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
dc6cdf405d
libvirt/tests/qemuxml2xmloutdata/q35-multifunction.x86_64-latest.xml

126 lines
5.5 KiB
XML
Raw Normal View History

qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<domain type='qemu'>
<name>q35-test</name>
<uuid>11dbdcdd-4c3b-482b-8903-9bdb8c0a2774</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static' cpuset='0-1'>2</vcpu>
<os>
<type arch='x86_64' machine='q35'>hvm</type>
<boot dev='hd'/>
</os>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>qemu64</model>
</cpu>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
tests: unify qemu binary paths for all qemu related tests Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-06 19:19:48 +03:00
<emulator>/usr/bin/qemu-system-x86_64</emulator>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='1' port='0x10'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='2' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='2' port='0x11'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
</controller>
<controller type='pci' index='3' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='3' port='0x12'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
</controller>
<controller type='pci' index='4' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='4' port='0x18'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='5' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='5' port='0x19'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1' multifunction='on'/>
</controller>
<controller type='pci' index='6' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='6' port='0x20'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='off'/>
</controller>
<controller type='pci' index='7' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='7' port='0x21'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
</controller>
<controller type='pci' index='8' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<target chassis='8' port='0x8'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='9' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='9' port='0x9'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='10' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='10' port='0xa'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='11' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='11' port='0xb'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='12' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='12' port='0xc'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='13' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='13' port='0xd'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='14' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='14' port='0xe'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x6'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='15' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='15' port='0xf'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x7'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='16' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='16' port='0x13'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='17' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='17' port='0x14'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
<controller type='pci' index='18' model='pcie-root-port'>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<model name='pcie-root-port'/>
conf: aggregate multiple pcie-root-ports onto a single slot Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so that they will be assigned to all the functions on a slot. Some qemu test case outputs had to be adjusted due to the pcie-root-ports now being put on multiple functions.
2016-10-20 22:46:01 +03:00
<target chassis='18' port='0x15'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
</controller>
qemuxml2xmltest: Convert all test cases asserting QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Turn them into DO_TEST_CAPS_LATEST tests so that we are closer to real world. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-08-25 17:44:55 +03:00
<controller type='usb' index='0' model='qemu-xhci'>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</controller>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
qemu: populate <audio> element with default config Currently the QEMU driver secretly sets the QEMU_AUDIO_DRV env variable - VNC - set to "none", unless passthrough of host env variable is set - SPICE - always set to "spice" - SDL - always passthrough host env - No graphics - set to "none", unless passthrough of host env variable is set The setting of the QEMU_AUDIO_DRV env variable is done in the code which configures graphics. If no <audio> element is present, we now auto-populate <audio> elements to reflect this historical default config. This avoids need to set audio env when processing graphics. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-24 17:24:10 +03:00
<audio id='1' type='none'/>
qemu: Add implicit watchdog for q35 machine types The iTCO watchdog is part of the q35 machine type since its inception, we just did not add it implicitly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2137346 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-20 13:22:22 +03:00
<watchdog model='itco' action='reset'/>
qemu: use virDomainPCIAddressSetAllMulti() to set multi when needed If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
2017-01-10 08:20:11 +03:00
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</memballoon>
</devices>
</domain>
Copy Permalink