openkylin
/
libvirt
mirror of https://gitee.com/openkylin/libvirt.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
libvirt/tests/qemuxml2argvdata/qemuxml2argv-q35.args

7 lines
385 B
Plaintext
Raw Normal View History

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-31 09:37:32 +08:00
LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \
/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-03 01:48:50 +08: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-31 09:37:32 +08:00
-device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 \
-vga qxl -global qxl.ram_size=67108864 -global qxl.vram_size=18874368