External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-08 14:29:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
1fd19670c6
libvirt/tests/qemuxml2argvdata/qemuxml2argv-aarch64-virt-2.6-virtio-pci-default.args

40 lines
1.3 KiB
Plaintext
Raw Normal View History

qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
LC_ALL=C \
PATH=/bin \
HOME=/home/test \
USER=test \
LOGNAME=test \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-aarch64 \
-name aarch64test \
-S \
-M virt-2.6 \
-cpu cortex-a53 \
-m 1024 \
qemu: caps: Always assume QEMU_CAPS_SMP_TOPOLOGY Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50 prior to 0.12.0, our minimum supported qemu version. $ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62 v0.11.0-rc0-449-gdc6b1c0 $ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab v0.12.0-rc0~1477
2016-06-23 11:29:16 +00:00
-smp 1,sockets=1,cores=1,threads=1 \
qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
-uuid 496d7ea8-9739-544b-4ebd-ef08be936e8b \
-nographic \
-nodefconfig \
-nodefaults \
-monitor unix:/tmp/lib/domain--1-aarch64test/monitor.sock,server,nowait \
qemu: Enforce ACPI, UEFI requirements Depending on the architecture, requirements for ACPI and UEFI can be different; more specifically, while on x86 UEFI requires ACPI, on aarch64 it's the other way around. Enforce these requirements when validating the domain, and make the error message more accurate by mentioning that they're not necessarily applicable to all architectures. Several aarch64 test cases had to be tweaked because they would have failed the validation step otherwise.
2017-03-09 15:38:26 +00:00
-no-acpi \
qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
-boot c \
-kernel /aarch64.kernel \
-initrd /aarch64.initrd \
-append 'earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait' \
-dtb /aarch64.dtb \
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
-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 \
-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \
-device ioh3420,port=0x10,chassis=3,id=pci.3,bus=pcie.0,addr=0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x2 \
qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
-drive file=/aarch64.raw,format=raw,if=none,id=drive-virtio-disk0 \
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
-device virtio-blk-pci,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,\
id=virtio-disk0 \
-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:09:a4:37,bus=pci.2,addr=0x1 \
qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
-net user,vlan=0,name=hostnet0 \
-serial pty \
-chardev pty,id=charconsole1 \
-device virtconsole,chardev=charconsole1,id=console1 \
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
-device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x4 \
qemu: support virt-2.6 machine type on arm Some places already check for "virt-" prefix as well as plain "virt". virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices having assigned the same unnumbered "pci" alias. Add a test for the "virt-2.6" machine type which also omits the <model type='virtio'/> in <interface>, to check if qemuDomainDefaultNetModel works too. https://bugzilla.redhat.com/show_bug.cgi?id=1325085
2016-04-08 08:46:41 +00:00
-object rng-random,id=objrng0,filename=/dev/random \
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
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x5
Reference in New Issue Copy Permalink