- 15 7月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Later on we're going to need access to information about IOMMU groups for host devices. Implement the support in virpcimock, and start using that mock library in a few QEMU test cases. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@laine.org>
-
- 11 7月, 2017 4 次提交
-
-
由 Cole Robinson 提交于
Every qemu version we support has QEMU_CAPS_CHARDEV, so stop explicitly tracking it and blacklist it like we've done for many other feature flags. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
These tests are exercising old style -serial command lines. That code will soon be removed, so drop these tests. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
AFAIK there aren't any qemu arch/machine types with platform parallel devices that would require old style -parallel config, so we shouldn't ever need this nowadays. Remove a now redundant test Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
This demonstrates that the previous qemu caps changes will use -chardev for pci-serial on aarch64 machvirt Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 20 6月, 2017 1 次提交
-
-
由 Farhan Ali 提交于
Update the per device boot schema to add an optional loadparm parameter. eg: <boot order='1' loadparm='2'/> Extend the virDomainDeviceInfo to support loadparm option. Modify the appropriate functions to parse loadparm from boot device xml. Add the xml2xml test to validate the field. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
-
- 13 6月, 2017 3 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1214369 Consider the following XML: <memoryBacking> <hugepages> <page size='2048' unit='KiB' nodeset='1'/> </hugepages> <source type='file'/> <access mode='shared'/> </memoryBacking> <numa> <cell id='0' cpus='0-3' memory='512000' unit='KiB'/> <cell id='1' cpus='4-7' memory='512000' unit='KiB'/> </numa> The following cmd line is generated: -object memory-backend-file,id=ram-node0,mem-path=/var/lib/libvirt/qemu/ram, share=yes,size=524288000 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-file,id=ram-node1,mem-path=/var/lib/libvirt/qemu/ram, share=yes,size=524288000 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1 This is obviously wrong as for node 1 hugepages should have been used. The hugepages configuration is more specific than <source type='file'/>. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1214369 https://bugzilla.redhat.com/show_bug.cgi?id=1458638 Historically, we've always supported memAccess for domains backed by hugepages. However, somewhere along the way we've regressed and stopped allowing such configuration. Fix it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We have couple of hugepage enabled domains for qemuxml2argvtest. Unfortunately, often when adding a test case there I forget to add it to xml2xml test too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 6月, 2017 3 次提交
-
-
由 Ján Tomko 提交于
Add a test case with all the virtio devices we know to demonstrate the addition of new options. https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Ján Tomko 提交于
Add a new iotlb attribute to the iommu device to control the device IOTLB support for intel-iommu. https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1459091 Currently, we are querying for vhostuser interface name in post parse callback. At that time interface might not yet exist. However, it has to exist when starting domain. Therefore it makes more sense to query its name at that point. This partially reverts 57b5e27d. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 5月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
Add an attribute to control extended interrupt mode. https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 16 5月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
Currently we consider all UNIX paths with specific prefix as generated by libvirt, but that's a wrong assumption. Let's make the detection better by actually checking whether the whole path matches one of the paths that we generate or generated in the past. The UNIX path isn't stored in config XML since libvirt-1.3.1. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446980Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 15 5月, 2017 2 次提交
-
-
由 Ján Tomko 提交于
Add a new attribute to control the caching mode. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
-
由 Ján Tomko 提交于
Add a new <ioapic> element with a driver attribute. Possible values are qemu and kvm. With 'qemu', the I/O APIC can be put in the userspace even for KVM domains. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
-
- 21 4月, 2017 1 次提交
-
-
由 Martin Kletzander 提交于
We are currently parsing only rx/frames/max because that's the only value that makes sense for us. The tun device just added support for this one and the others are only supported by hardware devices which we don't need to worry about as the only way we'd pass those to the domain is using <hostdev/> or <interface type='hostdev'/>. And in those cases the guest can modify the settings itself. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 4月, 2017 2 次提交
-
-
由 Pavel Hrdina 提交于
This removes the hacky extern global variable and modifies the test code to properly create QEMU capabilities cache for QEMU binaries used in our tests. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Commit 5572cd7f deprecated QEMU_CAPS_DEVICE capability but forgot to remove this call as well. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 04 4月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
We use the "vir" prefix pretty consistently in our APIs, both external and internal, which made these macros stood out.
-
- 27 3月, 2017 1 次提交
-
-
由 Erik Skultety 提交于
For now, these only cover the unmanaged, i.e. user pre-created devices. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 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 提交于
Now that NVDIMM has found its way into libvirt, users might want to fine tune some settings for each module separately. One such setting is 'share=on|off' for the memory-backend-file object. This setting - just like its name suggest already - enables sharing the nvdimm module with other applications. Under the hood it controls whether qemu mmaps() the file as MAP_PRIVATE or MAP_SHARED. Yet again, we have such config knob in domain XML, but it's just an attribute to numa <cell/>. This does not give fine enough tuning on per-memdevice basis so we need to have the attribute for each device too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
NVDIMM is new type of memory introduced into QEMU 2.6. The idea is that we have a Non-Volatile memory module that keeps the data persistent across domain reboots. At the domain XML level, we already have some representation of 'dimm' modules. Long story short, NVDIMM will utilize the existing <memory/> element that lives under <devices/> by adding a new attribute 'nvdimm' to the existing @model and introduce a new <path/> element for <source/> while reusing other fields. The resulting XML would appear as: <memory model='nvdimm'> <source> <path>/tmp/nvdimm</path> </source> <target> <size unit='KiB'>523264</size> <node>0</node> </target> <address type='dimm' slot='0'/> </memory> So far, this is just a XML parser/formatter extension. QEMU driver implementation is in the next commit. For more info on NVDIMM visit the following web page: http://pmem.io/Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 2月, 2017 2 次提交
-
-
由 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.
-
- 09 2月, 2017 1 次提交
-
-
由 Jaroslav Safka 提交于
This part introduces new xml elements for file based memorybacking support and their parsing. (It allows vhost-user to be used without hugepages.) New xml elements: <memoryBacking> <source type="file|anonymous"/> <access mode="shared|private"/> <allocation mode="immediate|ondemand"/> </memoryBacking>
-
- 26 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Not only we should set the MTU on the host end of the device but also let qemu know what MTU did we set. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Based on work of Mehdi Abaakouk <sileht@sileht.net>. When parsing vhost-user interface XML and no ifname is found we can try to fill it in in post parse callback. The way this works is we try to make up interface name from given socket path and then ask openvswitch whether it knows the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 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.
-
- 06 12月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Modify _virDomainBlockIoTuneInfo and rng schema to support the group_name option for iotune throttling. Document the new value. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 11月, 2016 1 次提交
-
-
由 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 3 次提交
-
-
由 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.
-