External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 05:35:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
libvirt/tests/qemuxmlconfdata/pci-autoadd-idx.x86_64-latest.xml

91 lines
3.4 KiB
XML
Raw Permalink Normal View History

qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<domain type='qemu'>
<name>fdr-br</name>
<uuid>3ec6cbe1-b5a2-4515-b800-31a61855df41</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static' cpuset='0-1'>2</vcpu>
<os>
tests: qemuxml2argvdata: Remove use of 'pc-1.0' and 'pc-1.2' machine types There's nothing special about the tests requiring to use very old machine types. Most usage is cargo-culted from other tests. Switch all the tests to use 'pc' instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-05 08:28:31 +00:00
<type arch='x86_64' machine='pc'>hvm</type>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
qemuxml2xmltest: Modernize all remaining fake capability tests Convert all cases using DO_TEST() to use DO_TEST_CAPS_LATEST() and remove DO_TEST() to prevent further use. Most of the changes are related to CPU being present in the output XML. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-08-15 13:45:51 +00:00
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>qemu64</model>
</cpu>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</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 16:19:48 +00:00
<emulator>/usr/bin/qemu-system-x86_64</emulator>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/iso/f18kde.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
qemuxml2xmltest: Modernize all remaining fake capability tests Convert all cases using DO_TEST() to use DO_TEST_CAPS_LATEST() and remove DO_TEST() to prevent further use. Most of the changes are related to CPU being present in the output XML. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-08-15 13:45:51 +00:00
<controller type='usb' index='0' model='piix3-uhci'>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<controller type='pci' index='1' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='1'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='2' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='2'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='3' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='3'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='4' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='4'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='5' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='5'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='6' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='6'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='pci' index='7' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='7'/>
conf: domain: Insert auto-added controllers in same order as in XML parser 'virDomainDefAddController' which is used in code-paths which auto-add controllers to the definition such as 'virDomainDefMaybeAddController', 'virDomainDefAddUSBController', 'qemuDomainDefAddDefaultDevices' was adding the controller at the end of the list. However that is not how the XML parser would order the controller in the list as it uses virDomainControllerInsert grouping them by type and additional properties. This would cause that auto-added controllers would re-order: - between first and any subsequent run of the VM (even on commandline) - after a libvirtd/virtqemud restart - after any update of the definition based on the 'define' operation (e.g. virsh edit) To ensure that the ordering of controllers is identical always use virDomainControllerInsert. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-12-18 17:32:57 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</controller>
<controller type='pci' index='8' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='8'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</controller>
device: cleanup input device code The current code was a little bit odd. At first we've removed all possible implicit input devices from domain definition to add them later back if there was any graphics device defined while parsing XML description. That's not all, while formating domain definition to XML description we at first ignore any input devices with bus different to USB and VIRTIO and few lines later we add implicit input devices to XML. This seems to me as a lot of code for nothing. This patch may look to be more complicated than original approach, but this is a preferred way to modify/add driver specific stuff only in those drivers and not deal with them in common parsing/formating functions. The update is to add those implicit input devices into config XML to follow the real HW configuration visible by guest OS. There was also inconsistence between our behavior and QEMU's in the way, that in QEMU there is no way how to disable those implicit input devices for x86 architecture and they are available always, even without graphics device. This applies also to XEN hypervisor. VZ driver already does its part by putting correct implicit devices into live XML. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-01-11 11:40:32 +00:00
<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 14:24:10 +00:00
<audio id='1' type='none'/>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<video>
domain_conf: always set primary video device as primary We always place primary video device at first place, to make it easier to create a qemu command or format an xml, but we should also set the primary boolean for primary video device to 'true'. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-02-23 12:00:24 +00:00
<model type='cirrus' vram='16384' heads='1' primary='yes'/>
qemu: auto-add bridges and allow using them Add a "dry run" address allocation to figure out how many bridges will be needed for all the devices without explicit addresses. Auto-add just enough bridges to put all the devices on, or up to the bridge with the largest specified index.
2013-04-19 10:38:53 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x04' slot='0x06' function='0x0'/>
</memballoon>
</devices>
</domain>
Reference in New Issue Copy Permalink