External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-02-04 10:55:19 +00:00
Code Issues Packages Projects Releases Wiki Activity
libvirt/tests/qemuxml2argvdata/qemuxml2argv-q35.args

9 lines
531 B
Plaintext
Raw Normal View History

qemu: Set QEMU_AUDIO_DRV=none with -nographic On my machine, a guest fails to boot if it has a sound card, but not graphical device/display is configured, because pulseaudio fails to initialize since it can't access $HOME. A workaround is removing the audio device, however on ARM boards there isn't any option to do that, so -nographic always fails. Set QEMU_AUDIO_DRV=none if no <graphics> are configured. Unfortunately this has massive test suite fallout. Add a qemu.conf parameter nographics_allow_host_audio, that if enabled will pass through QEMU_AUDIO_DRV from sysconfig (similar to vnc_allow_host_audio)
2013-08-17 15:30:47 -04:00
LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
qemu: add dmi-to-pci-bridge controller This PCI controller, named "dmi-to-pci-bridge" in the libvirt config, and implemented with qemu's "i82801b11-bridge" device, connects to a PCI Express slot (e.g. one of the slots provided by the pcie-root controller, aka "pcie.0" on the qemu commandline), and provides 31 *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31. Any time a machine is defined which has a pcie-root controller (i.e. any q35-based machinetype), libvirt will automatically add a dmi-to-pci-bridge controller if one doesn't exist, and also add a pci-bridge controller. The reasoning here is that any useful domain will have either an immediate (startup time) or eventual (subsequent hot-plug) need for a standard PCI slot; since the pcie-root controller only provides PCIe slots, we need to connect a dmi-to-pci-bridge controller to it in order to get a non-hot-plug PCI slot that we can then use to connect a pci-bridge - the slots provided by the pci-bridge will be both standard PCI and hot-pluggable. Since pci-bridge devices themselves can not be hot-plugged into a running system (although you can hot-plug other devices into a pci-bridge's slots), any new pci-bridge controller that is added can (and will) be plugged into the dmi-to-pci-bridge as long as it has empty slots available. This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST" to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit the automatically added dmi-to-pci-bridge and pci-bridge devices, and the "after" xml can include it - this way we are testing if libvirt is properly adding these devices.
2013-07-30 21:37:32 -04:00
/usr/libexec/qemu-kvm -S -M q35 -m 2048 -smp 2 -nographic -nodefaults \
-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \
qemu: properly set/use device alias for pci controllers We had been setting the device alias in the devinceinfo for pci controllers to "pci%u", but then hardcoding "pci.%u" when creating the device address for other devices using that pci bus. This all worked just fine until we encountered the built-in "pcie.0" bus (the PCIe root complex) in Q35 machines. In order to create the correct commandline for this one case, this patch: 1) sets the alias for PCI controllers correctly, to "pci.%u" (or "pcie.%u" for the pcie-root controller) 2) eliminates the hardcoded "pci.%u" for pci controllers when generatuing device address strings, and instead uses the controller's alias. 3) plumbs a pointer to the virDomainDef all the way down to qemuBuildDeviceAddressStr. This was necessary in order to make the aliase of the controller *used by a device* available (previously qemuBuildDeviceAddressStr only had the deviceinfo of the device itself, *not* of the controller it was connecting to). This made for a larger than desired diff, but at least in the future we won't have to do it again, since all the information we could possibly ever need for future enhancements is in the virDomainDef. (right?) This should be done for *all* controllers, but for now we just do it in the case of PCI controllers, to reduce the likelyhood of regression.
2013-08-02 13:48:50 -04:00
-device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x2 \
qemu: add dmi-to-pci-bridge controller This PCI controller, named "dmi-to-pci-bridge" in the libvirt config, and implemented with qemu's "i82801b11-bridge" device, connects to a PCI Express slot (e.g. one of the slots provided by the pcie-root controller, aka "pcie.0" on the qemu commandline), and provides 31 *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31. Any time a machine is defined which has a pcie-root controller (i.e. any q35-based machinetype), libvirt will automatically add a dmi-to-pci-bridge controller if one doesn't exist, and also add a pci-bridge controller. The reasoning here is that any useful domain will have either an immediate (startup time) or eventual (subsequent hot-plug) need for a standard PCI slot; since the pcie-root controller only provides PCIe slots, we need to connect a dmi-to-pci-bridge controller to it in order to get a non-hot-plug PCI slot that we can then use to connect a pci-bridge - the slots provided by the pci-bridge will be both standard PCI and hot-pluggable. Since pci-bridge devices themselves can not be hot-plugged into a running system (although you can hot-plug other devices into a pci-bridge's slots), any new pci-bridge controller that is added can (and will) be plugged into the dmi-to-pci-bridge as long as it has empty slots available. This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST" to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit the automatically added dmi-to-pci-bridge and pci-bridge devices, and the "after" xml can include it - this way we are testing if libvirt is properly adding these devices.
2013-07-30 21:37:32 -04:00
-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
qemu: enable using implicit sata controller in q35 machines q35 machines have an implicit ahci (sata) controller at 00:1F.2 which has no "id" associated with it. For this reason, we can't refer to it as "ahci0". Instead, we don't give an id on the commandline, which qemu interprets as "use the first ahci controller". We then need to specify the unit with "unit=%d" rather than adding it onto the bus arg.
2013-08-03 17:37:07 -04:00
-drive file=/dev/HostVG/QEMUGuest1,if=none,id=drive-sata0-0-0 \
-device ide-drive,unit=0,drive=drive-sata0-0-0,id=sata0-0-0 \
qemu: add dmi-to-pci-bridge controller This PCI controller, named "dmi-to-pci-bridge" in the libvirt config, and implemented with qemu's "i82801b11-bridge" device, connects to a PCI Express slot (e.g. one of the slots provided by the pcie-root controller, aka "pcie.0" on the qemu commandline), and provides 31 *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31. Any time a machine is defined which has a pcie-root controller (i.e. any q35-based machinetype), libvirt will automatically add a dmi-to-pci-bridge controller if one doesn't exist, and also add a pci-bridge controller. The reasoning here is that any useful domain will have either an immediate (startup time) or eventual (subsequent hot-plug) need for a standard PCI slot; since the pcie-root controller only provides PCIe slots, we need to connect a dmi-to-pci-bridge controller to it in order to get a non-hot-plug PCI slot that we can then use to connect a pci-bridge - the slots provided by the pci-bridge will be both standard PCI and hot-pluggable. Since pci-bridge devices themselves can not be hot-plugged into a running system (although you can hot-plug other devices into a pci-bridge's slots), any new pci-bridge controller that is added can (and will) be plugged into the dmi-to-pci-bridge as long as it has empty slots available. This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST" to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit the automatically added dmi-to-pci-bridge and pci-bridge devices, and the "after" xml can include it - this way we are testing if libvirt is properly adding these devices.
2013-07-30 21:37:32 -04:00
-vga qxl -global qxl.ram_size=67108864 -global qxl.vram_size=18874368
Reference in New Issue Copy Permalink