External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 21:55:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
deb3c834e5
libvirt/tests/qemuxml2xmloutdata/aarch64-virtio-pci-default.aarch64-latest.xml

95 lines
3.5 KiB
XML
Raw Normal View History

tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
<domain type='qemu'>
<name>aarch64test</name>
<uuid>496d7ea8-9739-544b-4ebd-ef08be936e8b</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='aarch64' machine='virt'>hvm</type>
<kernel>/aarch64.kernel</kernel>
<initrd>/aarch64.initrd</initrd>
<cmdline>earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait</cmdline>
<dtb>/aarch64.dtb</dtb>
<boot dev='hd'/>
</os>
<features>
<apic/>
<pae/>
qemu: Always enable GIC on ARM virt machines GIC is always available to ARM virt machines, and the domain XML should reflect this fact.
2016-02-03 18:49:27 +00:00
<gic version='2'/>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
</features>
qemu: Set default values for CPU check attribute Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-01 15:12:07 +00:00
<cpu mode='custom' match='exact' check='none'>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
<model fallback='allow'>cortex-a53</model>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-aarch64</emulator>
<disk type='file' device='disk'>
tests: qemuxml2xml: Remove testing with allowed format detection Nobody should use format detection due to security implications. The result of the change is that 'raw' format will be printed unless specified explicitly. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-02 14:43:55 +00:00
<driver name='qemu' type='raw'/>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
<source file='/aarch64.raw'/>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
<target dev='vda' bus='virtio'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
</disk>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
<controller type='pci' index='0' model='pcie-root'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<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 14:44:55 +00:00
<model name='pcie-root-port'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<target chassis='1' 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 19:46:01 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
</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 14:44:55 +00: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 19:46:01 +00:00
<target chassis='2' port='0x9'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
</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 14:44:55 +00: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 19:46:01 +00:00
<target chassis='3' port='0xa'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
</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 14:44:55 +00: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 19:46:01 +00:00
<target chassis='4' port='0xb'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
</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 14:44:55 +00: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 19:46:01 +00:00
<target chassis='5' port='0xc'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
</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 14:44:55 +00: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 19:46:01 +00:00
<target chassis='6' port='0xd'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
</controller>
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
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
<interface type='user'>
<mac address='52:54:00:09:a4:37'/>
<model type='virtio'/>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
</interface>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
<serial type='pty'>
conf: Add target type and model for pl011 We can finally introduce a specific target model for the pl011 device used by mach-virt guests, which means isa-serial will no longer show up to confuse users. We make sure migration works in both directions by interpreting the isa-serial target type, or the lack of target type, appropriately when parsing the guest XML, and skipping the newly-introduced type when formatting if for migration. We also verify that pl011 is not used for non-mach-virt guests and add a bunch of test cases. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=151292 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-09 16:14:57 +00:00
<target type='system-serial' port='0'>
<model name='pl011'/>
</target>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<console type='pty'>
<target type='virtio' port='1'/>
</console>
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'/>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
<memballoon model='virtio'>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
</memballoon>
<rng model='virtio'>
<backend model='random'>/dev/random</backend>
qemu: Use virtio-pci by default for mach-virt guests virtio-pci is the way forward for aarch64 guests: it's faster and less alien to people coming from other architectures. Now that guest support is finally getting there (Fedora 24, CentOS 7.3, Ubuntu 16.04 and Debian testing all support virtio-pci out of the box), we'd like to start using it by default instead of virtio-mmio. Users and applications can already opt-in by explicitly using <address type='pci'/> inside the relevant elements, but that's kind of cumbersome and requires all users and management applications to adapt, which we'd really like to avoid. What we can do instead is use virtio-mmio only if the guest already has at least one virtio-mmio device, and use virtio-pci in all other situations. That means existing virtio-mmio guests will keep using the old addressing scheme, and new guests will automatically be created using virtio-pci instead. Users can still override the default in either direction. Existing tests such as aarch64-aavmf-virtio-mmio and aarch64-virtio-pci-default already cover all possible scenarios, so no additions to the test suites are necessary.
2016-10-21 09:50:15 +00:00
<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
tests: qemu: More aarch64 virtio and pci tests Clarify the point of some of the test cases by renaming them. Add more xml2xml tests.
2016-01-27 22:47:14 +00:00
</rng>
tests: qemu: Add aarch64 virtio pci tests - qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default to virtio-mmio even if qemu is new enough to support PCI - qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
2015-09-30 00:10:07 +00:00
</devices>
</domain>
Reference in New Issue Copy Permalink