- 18 5月, 2017 1 次提交
-
-
由 Erik Skultety 提交于
Namely, this patch is about virMediatedDeviceGetIOMMUGroup{Dev,Num} functions. There's no compelling reason why these functions should take an object, on the contrary, having to create an object every time one needs to query the IOMMU group number, discarding the object afterwards, seems odd. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 16 5月, 2017 3 次提交
-
-
由 Andrea Bolognani 提交于
The QEMU default is GICv2, and some of the code in libvirt relies on the exact value. Stop pretending that's not the case and use GICv2 explicitly where needed. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
There are currently some limitations in the emulated GICv3 that make it unsuitable as a default. Use GICv2 instead. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1450433Signed-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 1 次提交
-
-
由 Ján Tomko 提交于
Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
-
- 03 5月, 2017 5 次提交
-
-
由 Michal Privoznik 提交于
Even though there are several checks before calling this function and for some scenarios we don't call it at all (e.g. on disk hot unplug), it may be possible to sneak in some weird files (e.g. if domain would have RNG with /dev/shm/some_file as its backend). No matter how improbable, we shouldn't unlink it as we would be unlinking a file from the host which we haven't created in the first place. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
Just like in previous commit, this fixes the same issue for hotplug. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
While the code allows devices to already be there (by some miracle), we shouldn't try to create devices that don't belong to us. For instance, we shouldn't try to create /dev/shm/file because /dev/shm is a mount point that is preserved. Therefore if a file is created there from an outside (e.g. by mgmt application or some other daemon running on the system like vhostmd), it exists in the qemu namespace too as the mount point is the same. It's only /dev and /dev only that is different. The same reasoning applies to all other preserved mount points. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to take given @device, get all kinds of info on it (major & minor numbers, owner, seclabels) and create its copy at a temporary location @path (usually /var/run/libvirt/qemu/$domName.dev), if @device live under /dev. This is, however, very loose condition, as it also means /dev/shm/* is created too. Therefor, we will need to pass more arguments into the function for better decision making (e.g. list of mount points under /dev). Instead of adding more arguments to all the functions (not easily reachable because some functions are callback with strictly defined type), lets just turn this one 'const char *' into a 'struct *'. New "arguments" can be then added at no cost. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
When setting up mount namespace for a qemu domain the following steps are executed: 1) get list of mountpoints under /dev/ 2) move them to /var/run/libvirt/qemu/$domName.ext 3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev 4) move the mountpoint of the new device tree to /dev 5) restore original mountpoints from step 2) Note the problem with this approach is that if some device in step 3) requires access to a mountpoint from step 2) it will fail as the mountpoint is not there anymore. For instance consider the following domain disk configuration: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/shm/vhostmd0'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </disk> In this case operation fails as we are unable to create vhostmd0 in the new device tree because after step 2) there is no /dev/shm anymore. Leave aside fact that we shouldn't try to create devices living in other mountpoints. That's a separate bug that will be addressed later. Currently, the order described above is rearranged to: 1) get list of mountpoints under /dev/ 2) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev 3) move them to /var/run/libvirt/qemu/$domName.ext 4) move the mountpoint of the new device tree to /dev 5) restore original mountpoints from step 3) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
- 28 4月, 2017 5 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
This is a USB3 controller and it's a better choice than piix3-uhci. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
The new logic will set the piix3-uhci if available regardless of any architecture and it will be updated to better model based on architecture and device existence. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Jiri Denemark 提交于
This patch maps /domain/cpu/cache element into -cpu parameters: - <cache mode='passthrough'/> is translated to host-cache-info=on - <cache level='3' mode='emulate'/> is transformed into l3-cache=on - <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off Any other <cache> element is forbidden. The tricky part is detecting whether QEMU supports the CPU properties. The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480, earlier QEMU releases enabled host-cache-info by default and had no way to disable it. If the property is present, it defaults to 'off' for any QEMU until at least 2.9.0. The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa. Earlier versions worked as if l3-cache=off was passed. For any QEMU until at least 2.9.0 l3-cache is 'off' by default. QEMU 2.9.0 was the first release which supports probing both properties by running device-list-properties with typename=host-x86_64-cpu. Older QEMU releases did not support device-list-properties command for CPU devices. Thus we can't really rely on probing them and we can just use query-cpu-model-expansion QMP command as a witness. Because the cache property probing is only reliable for QEMU >= 2.9.0 when both are already supported for quite a few releases, we let QEMU report an error if a specific cache mode is explicitly requested. The other mode (or both if a user requested CPU cache to be disabled) is explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case the QEMU defaults change. Any older QEMU already turns them off so not doing so explicitly does not make any harm. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 4月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Not all async jobs are visible via virDomainGetJobStats (either they are too fast or getting the stats is not allowed during the job), but forcing all of them to advertise the operation is easier than hunting the jobs for which fetching statistics is allowed. And we won't need to think about this when we add support for getting stats for more jobs. https://bugzilla.redhat.com/show_bug.cgi?id=1441563Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 24 4月, 2017 1 次提交
-
-
由 Yuri Chornoivan 提交于
-
- 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>
-
- 20 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
The history of USB controller for ppc64 guest is complex and goes back to libvirt 1.3.1 where the fun started. Prior Libvirt 1.3.1 if no model for USB controller was specified we've simply passed "-usb" on QEMU command line. Since Libvirt 1.3.1 there is a patch (8156493d) that fixes this issue by using "-device pci-ohci,..." but it breaks migration with older Libvirts which was agreed that's acceptable. However this patch didn't reflect this change in the domain XML and the model was still missing. Since Libvirt 2.2.0 there is a patch (f55eaccb) that fixes the issue with not setting the USB model into domain XML which we need to know about to not break the migration and since the default model was *pci-ohci* it was used as default in this patch as well. This patch tries to take all the previous changes into account and also change the default for newly defined domains that don't specify any model for USB controller. The VIR_DOMAIN_DEF_PARSE_ABI_UPDATE is set only if new domain is defined or new device is added into a domain which means that in all other cases we will use the old *pci-ohci* model instead of the better and not broken *nec-usb-xhci* model. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373184Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 18 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Introduce new wrapper functions without *Machine* in the function name that take the whole virDomainDef structure as argument and call the existing functions with *Machine* in the function name. Change the arguments of existing functions to *machine* and *arch* because they don't need the whole virDomainDef structure and they could be used in places where we don't have virDomainDef. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 10 4月, 2017 1 次提交
-
-
由 Marc Hartmayer 提交于
This way qemuDomainLogContextRef() and qemuDomainLogContextFree() is no longer needed. The naming qemuDomainLogContextFree() was also somewhat misleading. Additionally, it's easier to turn qemuDomainLogContext in a self-locking object. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
- 03 4月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
Depending on the architecture, requirements for ACPI and UEFI can be different; more specifically, while on x86 UEFI requires ACPI, on aarch64 it's the other way around. Enforce these requirements when validating the domain, and make the error message more accurate by mentioning that they're not necessarily applicable to all architectures. Several aarch64 test cases had to be tweaked because they would have failed the validation step otherwise.
-
由 Michal Privoznik 提交于
Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it doesn't work at all for other types like volume and network. So imagine that you have a domain that has a CDROM configured which source is a volume from an inactive pool. Because it is startupPolicy='optional', the CDROM is empty when the domain starts. However, the source element is not cleared out in the status XML and thus when the daemon restarts and tries to reconnect to the domain it refreshes the disks (which fails - the storage pool is still not running) and thus the domain is killed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 29 3月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
When idx is 0 virStorageFileChainLookup returns the base (bottom) of the backing chain rather than the top. This is expected by the callers of qemuDomainGetStorageSourceByDevstr. Add a special case for idx == 0
-
- 28 3月, 2017 3 次提交
-
-
由 Andrea Bolognani 提交于
For guests that use <memoryBacking><locked>, our only option is to remove the memory locking limit altogether. Partially-resolves: https://bugzilla.redhat.com/1431793
-
由 Andrea Bolognani 提交于
Instead of having a separate function, we can simply return zero from the existing qemuDomainGetMemLockLimitBytes() to signal the caller that the memory locking limit doesn't need to be set for the guest. Having a single function instead of two makes it less likely that we will use the wrong value, which is exactly what happened when we started applying the limit that was meant for VFIO-using guests to <memoryBacking><locked>-using guests.
-
由 Andrea Bolognani 提交于
This reverts commit c2e60ad0. Turns out this check is excessively strict: there are ways other than <memtune><hard_limit> to raise the memory locking limit for QEMU processes, one prominent example being tweaking /etc/security/limits.conf. Partially-resolves: https://bugzilla.redhat.com/1431793
-
- 27 3月, 2017 6 次提交
-
-
由 Erik Skultety 提交于
Since mdevs are just another type of VFIO devices, we should increase the memory locking limit the same way we do for VFIO PCI devices. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
As goes for all the other hostdev device types, grant the qemu process access to /dev/vfio/<mediated_device_iommu_group>. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
A mediated device will be identified by a UUID (with 'model' now being a mandatory <hostdev> attribute to represent the mediated device API) of the user pre-created mediated device. We also need to make sure that if user explicitly provides a guest address for a mdev device, the address type will be matching the device API supported on that specific mediated device and error out with an incorrect XML message. The resulting device XML: <devices> <hostdev mode='subsystem' type='mdev' model='vfio-pci'> <source> <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'> </source> </hostdev> </devices> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
The code is currently simple, but if we later add node names, it will be necessary to generate the names based on the node name. Add a helper so that there's a central point to fix once we add self-generated node names.
-
由 Peter Krempa 提交于
Looks up a disk and its corresponding backing chain element by node name.
-
- 25 3月, 2017 1 次提交
-
-
由 John Ferlan 提交于
If the migration flags indicate this migration will be using TLS, then set up the destination during the prepare phase once the target domain has been started to add the TLS objects to perform the migration. This will create at least an "-object tls-creds-x509,endpoint=server,..." for TLS credentials and potentially an "-object secret,..." to handle the passphrase response to access the TLS credentials. The alias/id used for the TLS objects will contain "libvirt_migrate". Once the objects are created, the code will set the "tls-creds" and "tls-hostname" migration parameters to signify usage of TLS. During the Finish phase we'll be sure to attempt to clear the migration parameters and delete those objects (whether or not they were created). We'll also perform the same reset during recovery if we've reached FINISH3. If the migration isn't using TLS, then be sure to check if the migration parameters exist and clear them if so.
-
- 17 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 16 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 3月, 2017 2 次提交
-
-
由 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>
-
由 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>
-
- 13 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1431112 Yeah, that's right. A mount point doesn't have to be a directory. It can be a file too. However, the code that tries to preserve mount points under /dev for new namespace for qemu does not count with that option. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1430634 If a qemu process has died, we get EOF on its monitor. At this point, since qemu process was the only one running in the namespace kernel has already cleaned the namespace up. Any attempt of ours to enter it has to fail. This really happened in the bug linked above. We've tried to attach a disk to qemu and while we were in the monitor talking to qemu it just died. Therefore our code tried to do some roll back (e.g. deny the device in cgroups again, restore labels, etc.). However, during the roll back (esp. when restoring labels) we still thought that domain has a namespace. So we used secdriver's transactions. This failed as there is no namespace to enter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-