- 23 3月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 17 3月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
We want pcie-root-ports to be used when available in QEMU, but at the same time we need to ensure that hosts running older QEMU releases keep working and that the user can override the default at any time. Add a comment for the original pcie-root-port test cases to make it clear how these new test cases are different.
-
- 15 3月, 2017 3 次提交
-
-
由 Michal Privoznik 提交于
For NVDIMM devices it is optionally possible to specify the size of internal storage for namespaces. Namespaces are a feature that allows users to partition the NVDIMM for different uses. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So, majority of the code is just ready as-is. Well, with one slight change: differentiate between dimm and nvdimm in places like device alias generation, generating the command line and so on. Speaking of the command line, we also need to append 'nvdimm=on' to the '-machine' argument so that the nvdimm feature is advertised in the ACPI tables properly. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 14 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 10 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
This is a very historic artefact. Back in the old days of 830ba76c when we had macros to add arguments onto qemu command line (!) we thought it was a good idea to let qemu write out the PID file. So we passed -pidfile $stateDir/$domName onto the command line. Thus, in order for tests to work we needed stable stateDir in the qemu driver. Unfortunately, after 16efa11a where stateDir is mkdtemp()-d, this approach lead to a leak of temp dir. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 3月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Laine Stump 提交于
While reviewing a patch from Andrea that modified this test case, I realized that although it was "properly failing" (it's a negative test), that it was failing for the wrong reason (the MULTIFUNCTION cap wasn't set in the test case, so it was saying that multifunction=on wasn't supported by the QEMU binary; instead it should have been complaining that it had run out of PCI slots of the appropriate type and couldn't automatically add any more). This improper failure had started when I added the patch to automatically aggregate pcie-root-ports onto multiple functions of each pcie-root slot, but I hadn't noticed it because the test still failed. This patch corrects the test case to 1) set the MULTIFUNCTION flag in the caps, and 2) attempt to add 241 pcie-root-ports to a domain. Since there are 30 slots available on a pcie-root (slot 0 is reserved, and slot 31 is used by the integrated SATA controller), and a pcie-root-port can only be placed on a function of a slot on pcie-root, the maximum number of pcie-root-ports in any domain is 240.
-
- 03 3月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
virQEMUCapsHasPCIMultiBus() performs a version check on the QEMU binary to figure out whether multiple buses are supported, so to get the correct aliases assigned when dealing with pSeries guests we need to spoof the version accordingly in the test suite.
-
由 Andrea Bolognani 提交于
Due to the extra architecture-specific logic, it's already necessary for users to call virQEMUCapsHasPCIMultiBus(), so the capability itself is just a pointless distraction.
-
- 24 2月, 2017 3 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1352529Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
Now that QEMU_CAPS_DEVICE_PCI_BRIDGE is no longer checked unless a pci-bridge is really part of the configuration, and most uses of the legacy PCI controller combo have been dropped from tests that use PCIe machine types, we can drop the corresponding capabilities from a lot of test cases.
-
由 Andrea Bolognani 提交于
In some cases, only one of the two transformations was checked; in other cases, the capabilities set differed.
-
- 17 2月, 2017 1 次提交
-
-
由 Marc-André Lureau 提交于
Add a new attribute 'rendernode' to <gl> spice element. Give it to QEMU if qemu supports it (queued for 2.9). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 13 2月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
This controller only allows up to 15 ports. https://bugzilla.redhat.com/show_bug.cgi?id=1375417
-
- 09 2月, 2017 1 次提交
-
-
由 Jaroslav Safka 提交于
This patch add support for file memory backing on numa topology. The specified access mode in memoryBacking can be overriden by specifying token memAccess in numa cell.
-
- 31 1月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
Commit 815d98ac started auto-adding one hub if there are more USB devices than available USB ports. This was a strange choice, since there might be even more devices. Before USB address allocation was implemented in libvirt, QEMU automatically added a new USB hub if the old one was full. Adjust the logic to try adding as many hubs as will be needed to plug in all the specified devices. https://bugzilla.redhat.com/show_bug.cgi?id=1410188
-
- 11 1月, 2017 2 次提交
-
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
-
- 10 1月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
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.
-
- 07 1月, 2017 3 次提交
-
-
由 Maxim Nestratov 提交于
Add a test case for when the QEMU_CAPS_NO_KVM_PIT capability is set. This capability is mutually exclusive to QEMU_CAPS_KVM_PIT_TICK_POLICY and results in the same output regardless of whether "discard" or "delay" was specified in the guest XML for 'tickpolicy'. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Separate out the "policy=discard" into it's own specific qemu command line. We'll rename "kvm-pit-device" test case to be "kvm-pit-discard" since it has the syntax we'd be using. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
By a mistake, for the VIR_DOMAIN_TIMER_TICKPOLICY_DELAY qemu command line creation, 'discard' was used instead of 'delay' in commit id '1569fa14'. Test "kvm-pit-delay" is fixed accordingly to show the correct option being generated. Remove the (now) redundant kvm-pit-device tests. As it turns out there is no need to specify both QEMU_CAPS_NO_KVM_PIT and QEMU_CAPS_KVM_PIT_TICK_POLICY since they are mutually exclusive and "kvm-pit-device" becomes just the same as "kvm-pit-delay". Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
- 06 1月, 2017 2 次提交
-
-
由 Collin L. Walling 提交于
Qemu has abandoned the +/-feature syntax in favor of key=value. Some architectures (s390) do not support +/-feature. So we update libvirt to handle both formats. If we detect a sufficiently new Qemu (indicated by support for qmp query-cpu-model-expansion) we use key=value else we fall back to +/-feature. Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
-
由 Jason J. Herne 提交于
Test cases for qemu s390x cpu model argument generation. Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
-
- 20 12月, 2016 1 次提交
-
-
由 Marc Hartmayer 提交于
Add tests for controller based disks to check disk address compatibility with disk bus types. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
- 06 12月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Add in the block I/O throttling group parameter to the command line if supported. If not supported, fail command creation. Add the xml2argvtest for testing. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 05 12月, 2016 1 次提交
-
-
由 Marc Hartmayer 提交于
Add test cases for address conflicts between disks and hostdevs that are using drive addresses. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 30 11月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
My overly sophisticated address reservation code forgot to add an error message for user-requested ports out of range. https://bugzilla.redhat.com/show_bug.cgi?id=1399260
-
- 28 11月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 11月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 25 11月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Eric Farman 提交于
With the QEMU components in place, provide the XML parsing to invoke that code when given the following XML snippet: <hostdev mode='subsystem' type='scsi_host'> <source protocol='vhost' wwpn='naa.501234567890abcd'/> </hostdev> An optional address element can be specified within the hostdev (pick CCW or PCI as necessary): <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0625'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> Add basic vhost-scsi tests which were cloned from hostdev-scsi-virtio-scsi in both xml2argv and xml2xml. Added ones for both vhost-scsi-ccw and vhost-scsi-pci since the syntaxes are slightly different between them. Also adjusted the docs to describe the changes. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 15 11月, 2016 5 次提交
-
-
由 Laine Stump 提交于
For machinetypes with a pci-root bus (all legacy PCI), libvirt will make a "fake" reservation for one extra slot prior to assigning addresses to unaddressed PCI endpoint devices in the domain. This will trigger auto-adding of a pci-bridge for the final device to be assigned an address *if that device would have otherwise instead been the last device on the last available pci-bridge*; thus it assures that there will always be at least one slot left open in the domain's bus topology for expansion (which is important both for hotplug (since a new pci-bridge can't be added while the guest is running) as well as for offline additions to the config (since adding a new device might otherwise in some cases require re-addressing existing devices, which we want to avoid)). It's important to note that for the above case (legacy PCI), we must check for the special case of all slots on all buses being occupied *prior to assigning any addresses*, and avoid attempting to reserve the extra address in that case, because there is no free address in the existing topology, so no place to auto-add a pci-bridge for expansion (i.e. it would always fail anyway). Since that condition can only be reached by manual intervention, this is acceptable. For machinetypes with pcie-root (Q35, aarch64 virt), libvirt's methodology for automatically expanding the bus topology is different - pcie-root-ports are plugged into slots (soon to be functions) of pcie-root as needed, and the new endpoint devices are assigned to the single slot in each pcie-root-port. This is done so that the devices are, by default, hotpluggable (the slots of pcie-root don't support hotplug, but the single slot of the pcie-root-port does). Since pcie-root-ports can only be plugged into pcie-root, and we don't auto-assign endpoint devices to the pcie-root slots, this means topology expansion doesn't compete with endpoint devices for slots, so we don't need to worry about checking for all "useful" slots being free *prior* to assigning addresses to new endpoint devices - as a matter of fact, if we attempt to reserve the open slots before the used slots, it can lead to errors. Instead this patch just reserves one slot for a "future potential" PCIe device after doing the assignment for actual devices, but only if the only PCI controller defined prior to starting address assignment was pcie-root, and only if we auto-added at least one PCI controller during address assignment. This assures two things: 1) that reserving the open slots will only be done when the domain is initially defined, never at any time after, and 2) that if the user understands enough about PCI controllers that they are adding them manually, that we don't mess up their plan by adding extras - if they know enough to add one pcie-root-port, or to manually assign addresses such that no pcie-root-ports are needed, they know enough to add extra pcie-root-ports if they want them (this could be called the "libguestfs clause", since libguestfs needs to be able to create domains with as few devices/controllers as possible). This is set to reserve a single free port for now, but could be increased in the future if public sentiment goes in that direction (it's easy to increase later, but essentially impossible to decrease)
-
由 Laine Stump 提交于
Real Q35 hardware has an ICH9 chip that includes several integrated devices at particular addresses (see the file docs/q35-chipset.cfg in the qemu source). libvirt already attempts to put the first two sets of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the real hardware. This patch does the same for the ich9 "HD audio" device. The main inspiration for this patch is that currently the *only* device in a reasonable "workstation" type virtual machine config that requires a legacy PCI slot is the audio device, Without this patch, the standard Q35 machine created by virt-manager will have a dmi-to-pci-bridge and a pci-bridge just for the sound device; with the patch (and if you change the sound device model from the default "ich6" to "ich9"), the machine definition constructed by virt-manager has absolutely no legacy PCI controllers - any legacy PCI devices (e.g. video and sound) are on pcie-root as integrated devices.
-
由 Laine Stump 提交于
Previously we added a set of EHCI+UHCI controllers to Q35 machines to mimic real hardware as closely as possible, but recent discussions have pointed out that the nec-usb-xhci (USB3) controller is much more virtualization-friendly (uses less CPU), so this patch switches the default for Q35 machinetypes to add an XHCI instead (if it's supported, which it of course *will* be). Since none of the existing test cases left out USB controllers in the input XML, a new Q35 test case was added which has *no* devices, so ends up with only the defaults always put in by qemu, plus those added by libvirt.
-
由 Laine Stump 提交于
Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot.
-
由 Laine Stump 提交于
The nec-usb-xhci device (which is a USB3 controller) has always presented itself as a PCI device when plugged into a legacy PCI slot, and a PCIe device when plugged into a PCIe slot, but libvirt has always auto-assigned it to a legacy PCI slot. This patch changes that behavior to auto-assign to a PCIe slot on systems that have pcie-root (e.g. Q35 and aarch64/virt). Since we don't yet auto-create pcie-*-port controllers on demand, this means a config with an nec-xhci USB controller that has no PCI address assigned will also need to have an otherwise-unused pcie-*-port controller specified: <controller type='pci' model='pcie-root-port'/> <controller type='usb' model='nec-xhci'/> (this assumes there is an otherwise-unused slot on pcie-root to accept the pcie-root-port)
-