External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 04:41:20 +00:00
Code Issues Packages Projects Releases Wiki Activity
029c36c981
libvirt/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-default.xml

91 lines
3.3 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'>
<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'/>
<controller type='virtio-serial' index='0'>
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='0x02' slot='0x00' function='0x0'/>
</controller>
<controller type='pci' index='1' model='pcie-root-port'>
<model name='ioh3420'/>
<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'>
<model name='ioh3420'/>
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'>
<model name='ioh3420'/>
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'>
<model name='ioh3420'/>
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'>
<model name='ioh3420'/>
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'>
<model name='ioh3420'/>
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>
<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'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<console type='pty'>
<target type='virtio' port='1'/>
</console>
<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