- 05 12月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
These XMLs live in a separate directory, there's no need for them to have a special prefix in addition. It also doesn't play nicely with ':e' completion in Vim, finding proper file based on qemuxml2argvtest.c is also needlessly complicated. The files were renamed using the following commands. From qemuxml2argvdata: for i in qemuxml2argv-*.xml; do mv $i ${i#qemuxml2argv-}; done and then (to fix broken symlinks) from qemuxml2argvdata and qemuxml2xmloutdata: for i in $(find . -xtype l); do \ ln -sf $(readlink $i | sed 's/qemuxml2argv-//') $i; done Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 23 2月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Up until a while ago, libvirt would automatically add a legacy PCI controllers combo (dmi-to-pci-bridge + pci-bridge) to any PCIe machine type (x86_64/q35 and aarch64/virt). As a result, a number of input and output files in the test suite ended up containing the legacy PCI controllers, even though they are not needed or in any way relevant to the feature being tested. Get rid of most of the occurrences. Most of the time, this just means removing the controllers from the input file and regenerating the output files; in a few instances, some minor tweaking is performed on the input file, most notably removing the memory balloon: as memory balloon support was not the scope of the test being changed, there is no loss of test coverage from doing so. Several occurrences of the legacy PCI controllers remain in the test suite, both because removing their usage would have required even more tweaking, and because we still want to have coverage of this perfectly valid combination.
-
- 11 5月, 2016 1 次提交
-
-
由 Laine Stump 提交于
libvirt may automatically add a pci-root or pcie-root controller to a domain, depending on the arch/machinetype, and it hopefully always makes the right decision about which to add (since in all cases these controllers are an implicit part of the virtual machine). But it's always possible that someone will create a config that explicitly supplies the wrong type of PCI controller for the selected machinetype. In the past that would lead to an error later when libvirt was trying to assign addresses to other devices, for example: XML error: PCI bus is not compatible with the device at 0000:00:02.0. Device requires a PCI Express slot, which is not provided by bus 0000:00 (that's the error message that appears if you replace the pcie-root controller in a Q35 domain with a pci-root controller). This patch adds a check at the same place that the implicit controllers are added (to ensure that the same logic is used to check which type of pci root is correct). If a pci controller with index='0' is already present, we verify that it is of the model that we would have otherwise added automatically; if not, an error is logged: The PCI controller with index='0' must be " model='pcie-root' for this machine type, " but model='pci-root' was found instead. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004602
-
- 09 1月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 06 8月, 2013 3 次提交
-
-
由 Laine Stump 提交于
This patch adds in special handling for a few devices that need to be treated differently for q35 domains: usb - there is no implicit/default usb controller for the q35 machinetype. This is done because normally the default usb controller is added to a domain by just adding "-usb" to the qemu commandline, and it's assumed that this will add a single piix3 usb1 controller at slot 1 function 2. That's not what happens when the machinetype is q35, though. Instead, adding -usb to the commandline adds 3 usb (version 2) controllers to the domain at slot 0x1D.{1,2,7}. Rather than having <controller type='usb' index='0'/> translate into 3 separate devices on the PCI bus, it's cleaner to not automatically add a default usb device; one can always be added explicitly if desired. Or we may decide that on q35 machines, 3 usb controllers will be automatically added when none is given. But for this initial commit, at least we aren't locking ourselves into something we later won't want. video - qemu always initializes the primary video device immediately after any integrated devices for the machinetype. Unless instructed otherwise (by using "-device vga..." instead of "-vga" which libvirt uses in many cases to work around deficiencies and bugs in various qemu versions) qemu will always pick the first unused slot. In the case of the "pc" machinetype and its derivatives, this is always slot 2, but on q35 machinetypes, the first free slot is slot 1 (since the q35's integrated peripheral devices are placed in other slots, e.g. slot 0x1f). In order to make the PCI address of the video device predictable, that slot (1 or 2, depending on machinetype) is reserved even when no video device has been specified. sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). ide - q35 has no ide controllers. isa and smbus controllers - these two are always present in a q35 (at slot 0x1F functions 0 and 3) but we have no way of modelling them in our config. We do need to reserve those functions so that the user doesn't attempt to put anything else there though. (note that the "pc" machine type also has an ISA controller, which we also ignore).
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
This controller is implicit on q35 machinetypes. It provides 31 PCIe (*not* PCI) slots as controller 0. Currently there are no devices that can connect to pcie-root, and no implicit pci controller on a q35 machine, so q35 is still unusable. For a usable q35 system, we need to add a "dmi-to-pci-bridge" pci controller, which can connect to pcie-root, and provides standard pci slots that can be used to connect other devices.
-