- 15 4月, 2019 4 次提交
-
-
由 Jiri Denemark 提交于
My earlier commit be46f613 was incomplete. It removed caching of microcode version in the CPU driver, which means the capabilities XML will see the correct microcode version. But it is also cached in the QEMU capabilities cache where it is used to detect whether we need to reprobe QEMU. By missing the second place, the original commit be46f613 made the situation even worse since libvirt would report correct microcode version while still using the old host CPU model (visible in domain capabilities XML). Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Support for kqemu was dropped in libvirt by commit 8e91a400 and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Daniel Henrique Barboza 提交于
The NVIDIA V100 GPU has an onboard RAM that is mapped into the host memory and accessible as normal RAM via an NVLink2 bridge. When passed through in a guest, QEMU puts the NVIDIA RAM window in a non-contiguous area, above the PCI MMIO area that starts at 32TiB. This means that the NVIDIA RAM window starts at 64TiB and go all the way to 128TiB. This means that the guest might request a 64-bit window, for each PCI Host Bridge, that goes all the way to 128TiB. However, the NVIDIA RAM window isn't counted as regular RAM, thus this window is considered only for the allocation of the Translation and Control Entry (TCE). For more information about how NVLink2 support works in QEMU, refer to the accepted implementation [1]. This memory layout differs from the existing VFIO case, requiring its own formula. This patch changes the PPC64 code of @qemuDomainGetMemLockLimitBytes to: - detect if we have a NVLink2 bridge being passed through to the guest. This is done by using the @ppc64VFIODeviceIsNV2Bridge function added in the previous patch. The existence of the NVLink2 bridge in the guest means that we are dealing with the NVLink2 memory layout; - if an IBM NVLink2 bridge exists, passthroughLimit is calculated in a different way to account for the extra memory the TCE table can alloc. The 64TiB..128TiB window is more than enough to fit all possible GPUs, thus the memLimit is the same regardless of passing through 1 or multiple V100 GPUs. Further reading explaining the background [1] https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03700.html [2] https://www.redhat.com/archives/libvir-list/2019-March/msg00660.html [3] https://www.redhat.com/archives/libvir-list/2019-April/msg00527.htmlSigned-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Daniel Henrique Barboza 提交于
The NVLink2 support in QEMU implements the detection of NVLink2 capable devices by verifying the attributes of the VFIO mem region QEMU allocates for the NVIDIA GPUs. To properly allocate an adequate amount of memLock, Libvirt needs this information before a QEMU instance is even created, thus querying QEMU is not possible and opening a VFIO window is too much. An alternative is presented in this patch. Making the following assumptions: - if we want GPU RAM to be available in the guest, an NVLink2 bridge must be passed through; - an unknown PCI device can be classified as a NVLink2 bridge if its device tree node has 'ibm,gpu', 'ibm,nvlink', 'ibm,nvlink-speed' and 'memory-region'. This patch introduces a helper called @ppc64VFIODeviceIsNV2Bridge that checks the device tree node of a given PCI device and check if it meets the criteria to be a NVLink2 bridge. This new function will be used in a follow-up patch that, using the first assumption, will set up the rlimits of the guest accordingly. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 13 4月, 2019 4 次提交
-
-
由 Martin Kletzander 提交于
This does not cause a problem in usual scenarios thanks to us allowing CAP_DAC_OVERRIDE for the qemu process, however in some scenarios this might be an issue because the directory is created with mkdtemp(3) which explicitly creates that with 0700 permissions and qemu running as non-root cannot access that. The scenarios include: - Builds without CAPNG - Running libvirtd in certain container configurations [1] - and possibly others. [1] https://github.com/kubevirt/kubevirt/pull/2181#issuecomment-481840304Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
The structure can only be used for CPUID data now. Adding a type indicator and moving the data into a union will let us store alternative data types. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
It's called virCPUx86DataAdd now. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The following patches introduce CPU features read from MSR in addition to those queried via CPUID instruction. Let's introduce a container struct which will be able to describe either feature type. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 12 4月, 2019 5 次提交
-
-
由 Andrea Bolognani 提交于
Vim has trouble figuring out the filetype automatically because the name doesn't follow existing conventions; annotations like the ones we already have in Makefile.ci help it out. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
The latter is deprecated and will be removed soon. The advised replacement is '-overcommit mem-lock=on|off'. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Added in QEMU commit of v3.0.0-rc0~48^2~9 (then fixed by v3.1.0-rc0~119^2~37) QEMU is replacing '-realtime mlock' with '-overcommit mem-lock'. Add a capability to tell if we're dealing new new enough qemu to use the replacement. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
The '-realtime mlock' cmd line argument was introduced in QEMU commit v1.5.0-rc0~190 which matches minimal QEMU version we require. Therefore, the capability will always be present. Apparently, nearly none of our xml2argv test cases had the capability hence slightly bigger change under qemuxml2argvdata/. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Cole Robinson 提交于
Standardize on putting the _LAST enum value on the second line of VIR_ENUM_IMPL invocations. Later patches that add string labels to VIR_ENUM_IMPL will push most of these to the second line anyways, so this saves some noise. Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 10 4月, 2019 21 次提交
-
-
由 Peter Krempa 提交于
Demonstrate how VIR_RETURN_PTR is used by refactoring qemu_block.c Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
This is a locally used helper struct but we can make use of automatic freeing for it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Also free the backends array, not just its members. Fixes: d3f9dda2Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
It is no longer used. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Commit 6864d8f7 moved this one level up for qemuBuildMemoryBackendProps but left qemuBuildMemPathStr intact. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Use qemuBuildMemoryGetDefaultPagesize. Fixes: 6864d8f7Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Acked-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Acked-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
This part of the code will be reused later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Acked-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Michal Privoznik 提交于
This piece of code will be reused later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Acked-by: NLaszlo Ersek <lersek@redhat.com>
-
由 Peter Krempa 提交于
This reverts commit a5e16020. Getting rid of unistd.h from our headers will require more work than just fixing the broken mingw build. Revert it until I have a more complete proposal. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
util/virutil.h bogously included unistd.h. Drop it and replace it by including it directly where needed. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
virutil.(c|h) is a very gross collection of random code. Remove the enum handlers from there so we can limit the scope where virtutil.h is used. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
'viralloc.h' does not provide any type or macro which would be necessary in headers. Prevent leakage of the inclusion. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Keeping them with viralloc.h forcibly pulls in the other stuff from viralloc.h into other header files. This in turn creates a mess as more and more headers pull in the 'viral' header file. If we want to make 'viralloc.h' omnipresent we should pick a different approach. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 04 4月, 2019 5 次提交
-
-
由 Andrea Bolognani 提交于
The rules are the same for all virt guests, regardless of the architecture. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Andrea Bolognani 提交于
Our PCIe topology depends on the availability of PCIe Root Ports, so if none of the suitable devices (pcie-root-port, ioh3420) is compiled into QEMU we should fall back to virtio-mmio rather than trying to use PCI addresses only to fail immediately afterwards when we realize we can't use the necessary controllers. Note that this additional check is basically moot for ARM virt guests, because PCIe Root Ports were enabled in QEMU builds for the architecture well before guest OS support had been widely available; however, the opposite is true for RISC-V, and tweaking the code this way will allow us to share it between architectures. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Since the STOP event handler can use the pausedReason as sent to qemuProcessStopCPUs, we no longer need to send duplicate suspended lifecycle events because we know what caused the stop along with extra details. This processing allows us to also remove the duplicated state change from qemuProcessStopCPUs. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Map is based on existing cases in code where we send suspended event after changing domain state to paused. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
由 Nikolay Shirokovskiy 提交于
Similar to commit [1] which saves and passes the running reason to the RESUME event handler, during qemuProcessStopCPUs let's save and pass the pause reason in the domain private data so that the STOP event handler can use it. [1] 5dab984e : qemu: Pass running reason to RESUME event handler Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-
- 03 4月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1693066 Up until memfd introduction (in 24b74d18) we did not need to know @pagesize because qemuGetDomainHupageMemPath() could deal with it being zero (value of zero means use the default hugetlbfs mount). But since for memfd we are not passing a path to hugetlbfs mount rather the page size value we need to know its value upfront. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-