24404 Commits

Author SHA1 Message Date
Michal Privoznik
0a97486e09 cpu_x86: Fix placement of *CheckFeature functions
In e17d10386 these functions were mistakenly moved into an #ifdef
block, but remained used outside of it leaving the build broken
for platforms where #ifdef evaluated to false.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-04-15 09:48:05 +02:00
Michal Privoznik
ae3d812b00 virhostcpu: Make virHostCPUGetMSR() work only on x86
Model specific registers are a thing only on x86. Also, the
/dev/cpu/0/msr path exists only on Linux and the fallback
mechanism (asking KVM) exists on Linux and FreeBSD only.

Therefore, move the function within #ifdef that checks all
aforementioned constraints and provide a dummy stub for all
other cases.

This fixes the build on my arm box, mingw-* builds, etc.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-04-15 09:46:27 +02:00
Michal Privoznik
b9991e8386 virhostcpu.c: Fix misalignment in virHostCPUGetMSRFromKVM comment
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-04-15 09:39:11 +02:00
Daniel Henrique Barboza
1a922648f6 PPC64 support for NVIDIA V100 GPU with NVLink2 passthrough
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.html

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-15 07:41:43 +02:00
Daniel Henrique Barboza
cc9f03801c qemu_domain: NVLink2 bridge detection function for PPC64
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: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-04-15 07:06:52 +02:00
Michal Privoznik
4a0f604dd0 cpu_map: Distribute x86_Cascadelake-Server.xml
In 2878278c74cc4 we've added new cpu model but we've forgot to
distribute the XML file it comes in.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-04-13 21:33:22 +02:00
Martin Kletzander
673f805d4d qemu: Label uniqDir when probing capabilities
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-481840304

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-13 00:56:45 +02:00
Jiri Denemark
df4b46737f vircpuhost: Add support for reading MSRs
The new virHostCPUGetMSR internal API will try to read the MSR from
/dev/cpu/0/msr and if it is not possible (the device does not exist or
libvirt is running unprivileged), it will fallback to asking KVM for the
MSR using KVM_GET_MSRS ioctl.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:40 +02:00
Jiri Denemark
e17d10386b cpu_x86: Move *CheckFeature functions
They are static and we will need to call them a little bit closer to the
beginning of the file.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
fcf4846a6b cpu_x86: Add support for storing MSR features in CPU map
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
370177e2f6 cpu_x86: Store virCPUx86DataItem content in union
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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
10b80165db cpu_x86: Make x86cpuidMatch more general
The function now works on virCPUx86DataItem and it's called
virCPUx86DataItemMatch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
2eea67a98e cpu_x86: Make x86cpuidMatchMasked more general
The function is renamed as virCPUx86DataItemMatchMasked to reflect the
change in parameter types.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
da1efddfa6 cpu_x86: Make x86cpuidAndBits more general
The function now works on virCPUx86DataItem and it's renamed as
virCPUx86DataItemAndBits.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
4e3cab2d00 cpu_x86: Make x86cpuidClearBits more general
The parameters changed from virCPUx86CPUID to virCPUx86DataItem and the
function is now called virCPUx86DataItemClearBits.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
9c6f00fc33 cpu_x86: Make x86cpuidSetBits more general
The function is renamed as virCPUx86DataItemSetBits and it works on
virCPUx86DataItem now.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
559ccd7815 cpu_x86: Introduce virCPUx86DataCmp
virCPUx86DataSorter already compares two virCPUx86DataItem structs.
Let's add a tiny wrapper around it called virCPUx86DataCmp and use it
instead of open coded comparisons.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
0fdc0ad84c cpu_x86: Simplify x86DataAdd
The while loop just copied half of virCPUx86DataAddItem.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
3eff71a2d5 cpu_x86: Rename virCPUx86VendorToCPUID
Renamed as virCPUx86VendorToData.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
8f1a8ce397 cpu_x86: Rename virCPUx86DataAddCPUID
It's called virCPUx86DataAdd now.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
ce42042577 cpu_x86: Rename virCPUx86DataAddCPUIDInt
The new name is virCPUx86DataAddItem.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
95accfa7fa cpu_x86: Rename virCPUx86CPUIDSorter
It is called virCPUx86DataSorter since the function will work on any CPU
data type.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
609f467f13 cpu_x86: Rename x86DataCpuid
It is now called virCPUx86DataGet.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
5655b83139 cpu_x86: Rename x86DataCpuidNext function
The function is now called virCPUx86DataNext to reflect its purpose: it
is an iterator over CPU data (both CPUID and MSR in the near future).

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
6c22b329d5 cpu_x86: Rename virCPUx86DataItem variables
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
c02d70d52e cpu_x86: Rename virCPUx86Vendor.cpuid
Although vendor string is always reported by CPUID, the container struct
is used for consistency and thus "cpuid" name is not a good fit anymore.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
3673269e3a cpu_x86: Introduce virCPUx86DataItem container struct
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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Jiri Denemark
2878278c74 cpu_map: Add Cascadelake-Server CPU model
Introduced in QEMU 3.1.0 by commit
c7a88b52f62b30c04158eeb07f73e3f72221b6a8

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 22:53:39 +02:00
Andrea Bolognani
03a07357e1 maint: Add filetype annotations to Makefile.inc.am
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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 16:55:38 +02:00
Michal Privoznik
51f17c98f6 lib: Don't use virReportSystemError() if virCommandRun() fails
Firstly, virCommandRun() does report an error on failure (which
in most cases is more accurate than what we overwrite it with).
Secondly, usually errno is not set (or gets overwritten in the
cleanup code) which makes virReportSystemError() report useless
error messages. Drop all virReportSystemError() calls in cases
like this (I've found three occurrences).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 15:56:28 +02:00
Andrea Bolognani
5aefd1362f conf: Fix typo enconding -> encoding
Introduced-by: e0fae78ad550
Spotted-by: Lintian
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2019-04-12 14:33:42 +02:00
Michal Privoznik
e8c2c8bd07 qemu_command: Prefer '-overcommit mem-lock' over -realtime mlock'
The latter is deprecated and will be removed soon. The advised
replacement is '-overcommit mem-lock=on|off'.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 14:13:45 +02:00
Michal Privoznik
be51feff69 qemu_capabilities: Introduce QEMU_CAPS_OVERCOMMIT
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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 13:42:39 +02:00
Michal Privoznik
a08c4b3741 qemu: Always assume QEMU_CAPS_REALTIME_MLOCK
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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 13:39:42 +02:00
Pavel Hrdina
e3c4befef4 virresctrl: fix MBA memory leak
The 'bandwidths' variable is allocated using VIR_RESIZE_N so it has to
be freed as well.

==118315== 8 bytes in 1 blocks are definitely lost in loss record 299 of 2,401
==118315==    at 0x4C29DAD: malloc (vg_replace_malloc.c:308)
==118315==    by 0x4C2C100: realloc (vg_replace_malloc.c:836)
==118315==    by 0x52C3FAF: virReallocN (viralloc.c:245)
==118315==    by 0x52C4079: virExpandN (viralloc.c:294)
==118315==    by 0x532BBA8: virResctrlAllocParseProcessMemoryBandwidth (virresctrl.c:1156)
==118315==    by 0x532BBA8: virResctrlAllocParseMemoryBandwidthLine (virresctrl.c:1211)
==118315==    by 0x532BBA8: virResctrlAllocParse (virresctrl.c:1414)
==118315==    by 0x532BBA8: virResctrlAllocGetGroup (virresctrl.c:1446)
==118315==    by 0x532C11D: virResctrlAllocGetDefault (virresctrl.c:1464)
==118315==    by 0x532D15E: virResctrlAllocAssign (virresctrl.c:1923)
==118315==    by 0x532D15E: virResctrlAllocCreate (virresctrl.c:2042)
==118315==    by 0x31E1ABEE: qemuProcessResctrlCreate (qemu_process.c:2596)
==118315==    by 0x31E1ABEE: qemuProcessLaunch (qemu_process.c:6444)
==118315==    by 0x31E1E341: qemuProcessStart (qemu_process.c:6721)
==118315==    by 0x31E81315: qemuDomainObjStart.constprop.50 (qemu_driver.c:7288)
==118315==    by 0x31E81A65: qemuDomainCreateWithFlags (qemu_driver.c:7341)
==118315==    by 0x54DDB4B: virDomainCreate (libvirt-domain.c:6534)

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2019-04-12 12:39:42 +02:00
Andrea Bolognani
4637048f8d src: Include SASL_CFLAGS where appropriate
A bunch of files include src/rpc/virnetsaslcontext.h, which
in turn includes <sasl/sasl.h>, and without the corresponding
CFLAGS the compiler can't locate the latter if it happens to
be installed outside of the default include path as is the
case, for example, on FreeBSD.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-12 09:16:02 +02:00
Cole Robinson
1d31526b52 Always put _LAST enums on second line of VIR_ENUM_IMPL
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: Cole Robinson <crobinso@redhat.com>
2019-04-11 12:47:23 -04:00
Daniel P. Berrangé
ae076bb40e remote: enforce ACL write permission for getting guest time & hostname
Getting the guest time and hostname both require use of guest agent
commands. These must not be allowed for read-only users, so the
permissions check must validate "write" permission not "read".

Fixes CVE-2019-3886
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-11 15:21:53 +01:00
Daniel P. Berrangé
2a07c990bd api: disallow virDomainGetHostname for read-only connections
The virDomainGetHostname API is fetching guest information and this may
involve use of an untrusted guest agent. As such its use must be
forbidden on a read-only connection to libvirt.

Fixes CVE-2019-3886
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-11 15:21:48 +01:00
Daniel P. Berrangé
d5cbf85f1a build-aux: ensure all scripts are included in EXTRA_DIST
Few of the scripts in build-aux are included in EXTRA_DIST. This is not
a serious problem since they are primarily tools intended for developers
upstream, and downstream builds won't need them. Having them missing,
however, complicates downstream patching because it means patches that
are auto-exported from git will fail to apply if they include a change
to a file in build-aux/.  By bundling all these scripts in the dist we
make patching more straightforward.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-11 15:20:17 +01:00
Pavel Hrdina
6d82b979d0 libvirtd.conf: remove extra # after log_outputs line
The only place where we have extra empty comment line.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2019-04-11 15:04:55 +02:00
Peter Krempa
17f160b288 util: json: Use VIR_APPEND_ELEMENT in virJSONValueObjectAppend
The function open-codes addition into an array. Use the helper instead.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
0ef161c88f qemu: block: Use VIR_RETURN_PTR
Demonstrate how VIR_RETURN_PTR is used by refactoring qemu_block.c

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
267f1e6da5 internal: Introduce VIR_RETURN_PTR
With the introduction of more and more internal data types which support
VIR_AUTOPTR it's becoming common to see the following pattern:

  VIR_AUTOPTR(virSomething) some = NULL
  virSomethingPtr ret = NULL;

  ... (ret is not touched ) ...

  VIR_STEAL_PTR(ret, some);
  return ret;

This patch introduces a macro named VIR_RETURN_PTR which returns the
pointer directly without the need for an explicitly defined return
variable and use of VIR_STEAL_PTR. Internally obviously a temporary
pointer is created to allow setting the original pointer to NULL so that
the VIR_AUTOPTR function does not free the memory which we want to
actually return.

The name of the temporary variable is deliberately long and complex to
minimize the possibility of collision.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
c9cec6a8b0 qemu: block: Remove unneeded cleanup jumps
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
6542fbe2d5 qemu: block: Add and use AUTOPTR func for qemuBlockNodeNameBackingChainData
This is a locally used helper struct but we can make use of automatic
freeing for it.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
7141bdd5bf qemu: block: Use VIR_AUTOFREE for char *
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
ae0c36ecbb qemu: block: Use VIR_AUTOPTR for virHashTablePtr
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
bc6eabbec3 qemu: block: Use VIR_AUTOPTR for virURIPtr
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00
Peter Krempa
46bd9ee7d7 util: uri: Introduce VIR_AUTOPTR freeing function
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-10 16:34:57 +02:00