By default, qemu user's home dir points to '/' which shouldn't be used
at all. We therefore pass the HOME variable from the current variable
iff not running as SUID, which means that for systemd we never set it.
This patch makes sure, that for system QEMU this is always set to
libDir/<driver>, session mode is left untouched.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For session mode, only XDG_CACHE_HOME is set, because we want to remain
integrating with services in user session, but for system mode, this
would have become reading/writing to '/' which carries the obvious issue
with permissions (also, '/' is the wrong location in 99.9% cases anyway).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Some modules/libraries within QEMU could make use of the XDG_ vars when
writing their data to the disk. Define the most common XDG variables
and point them to the specific driver's libDir, i.e.
XDG_CACHE_HOME -> /var/lib/libvirt/<driver>/.cache
XDG_DATA_HOME -> /var/lib/libvirt/<driver>/.local/share
XDG_CONFIG_HOME -> /var/lib/libvirt/<driver>/.config
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
After commits e2087c2 and ec0793de older GCC started act very smart and
complain about potentially uninitialized variable, which existed prior
to these patches + even if the affected vars were left uninitialized the
function responsible for filling them in would have failed with NULL
being returned which the caller has always handled carefully.
Although GCC complained only about a single variable, let's initialize
all of them so as to prevent any further potential breakages.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Luckily, the new URL still points to the same location, the only change
is in the document name where an escaped space (%20) was replaced by an
underscore.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This is mainly about /dev/sev and its default permissions 0600. Of
course, rule of 'tinfoil' would be that we can't trust anything, but the
probing code in QEMU is considered safe from security's perspective + we
can't create an udev rule for this at the moment, because ioctls and
file system permissions aren't cross-checked in kernel and therefore a
user with read permissions could issue a 'privileged' operation on SEV
which is currently only limited to root.
https://bugzilla.redhat.com/show_bug.cgi?id=1665400
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The default permissions (0600 root:root) are of no use to the qemu
process so we need to change the owner to qemu iff running with
namespaces.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of exposing /dev/sev to every domain, do it selectively.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
SEV has a limit on number of concurrent guests. From security POV we
should only expose resources (any resources for that matter) to domains
that truly need them.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We should not give domains access to something they don't necessarily
need by default. Remove it from the qemu driver docs too.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, all of the VirtioOptions are under a single <optional>
element, however, neither our parser/formatter or QEMU driver requires
the presence of all the options if only a single one from the set has
been specified, so fix it and silence the schema validator.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Before launching a SEV guest we take the base64-encoded guest owner's
data specified in launchSecurity and create files with the same content
under /var/lib/libvirt/qemu/<domain>. The reason for this is that we
need to pass these files on to QEMU which then uses them to communicate
with the SEV firmware, except when it doesn't have permissions to open
those files since we don't relabel them.
https://bugzilla.redhat.com/show_bug.cgi?id=1658112
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Since SEV operates on a per domain basis, it's very likely that all
SEV launch-related data will be created under
/var/lib/libvirt/qemu/<domain_name>. Therefore, when calling into
qemuProcessSEVCreateFile we can assume @libDir as the directory prefix
rather than passing it explicitly.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
For some reason, xdr_free uses char * instead of void * for its 2nd
argument which is passed to a custom free routine. Commit
dc54b3ec missed this detail which made the build fail on a number of
platforms. Fix it by explicitly casting the object pointer to char *
just like we do in other places throughout the code base.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The QEMU validation code for graphics has been in place for a while, but
because it is only executed from virDomainDeviceInfoIterateInternal, it
was never run, since the iterator expects the device to have boot info
which graphics don't have. The unfortunate side effect of this whole mess
was that a few capabilities were missing from the test suite (as commit
d8266ebe1 demonstrated with graphics-spice-invalid-egl-headless test),
which in turn meant that a few graphics tests which expected a failure
happily accepted any failure the test runtime returned which made them
succeed. The impact of this was that we then allowed to start a domain
with multiple OpenGL-enabled graphics devices.
This patch enables iteration over graphics devices. Unsurprisingly,
a few tests started to fail as a result, so fix those too.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It's fairly easy to forget to add a capability to the list of
capabilities for a negative test case which might yield (for us) very
unfortunate results. Therefore, introduce negative versions of
DO_TEST_CAPS_LATEST macros, so that real QEMU caps can be used with
tests that expect a failure too.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Validation of domain devices is accomplished via a generic device
iterator which takes a callback, iterates over all kinds of supported
device types and invokes the callback on every single device. However,
there might be cases when we need to alter the behaviour of the
iteration (most notably skip or include a group of devices). Therefore,
this patch introduces iterator flags.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since the code was never run, it would have been very hard to spot this
mistake, especially since the compiler can't really warn about it.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit 255e0732 introduced a few graphics-related helpers. The problem
is that virDomainGraphicsNeedsAutoRenderNode returns true if it gets
NULL as a response from virDomainGraphicsNeedsAutoRenderNode. That's
okay for egl-headless because that one always needs a DRM render node,
the same is not true for SPICE though, and unless the XML specifies
<gl enable='yes'> for SPICE, there's no need for any renderer.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Just like for SPICE, we need to change the permissions on the DRI device
used as the @rendernode for egl-headless graphics type.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Just like for SPICE, we need to put the render node DRI device into the
device cgroup list so that users don't need to add it manually via
qemu.conf file.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Just like for SPICE, we need to put the DRI device into the namespace,
otherwise it will be left out from the DAC relabeling process.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unlike with SPICE and SDL which use the <gl> subelement to enable OpenGL
acceleration, specifying egl-headless graphics in the XML has
essentially the same meaning, thus in case of egl-headless we don't have
a need for the 'enable' element attribute and we'll only be interested
in the 'rendernode' one further down the road.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since we need to specify the rendernode option onto QEMU cmdline, we
need this union member to retain consistency in how we build the
cmdline.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have QAPI introspection of display types in QEMU upstream,
we can check whether the 'rendernode' option is supported with
egl-headless display type.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We're going to need a bit more logic for egl-headless down the road so
prepare a helper just like for the other display types.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Up until now, we formatted 'rendernode=' onto QEMU cmdline only if the
user specified it in the XML, otherwise we let QEMU do it for us. This
causes permission issues because by default the /dev/dri/renderDX
permissions are as follows:
crw-rw----. 1 root video
There's literally no reason why it shouldn't be libvirt picking the DRM
render node instead of QEMU, that way (and because we're using
namespaces by default), we can safely relabel the device within the
namespace.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A few simple helpers that allow us to determine whether a graphics can
and will need to make use of a DRM render node.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is the first step towards libvirt picking the first available
render node instead of QEMU. It also makes sense for us to be able to do
that, since we allow specifying the node directly for SPICE, so if
there's no render node specified by the user, we should pick the first
available one. The algorithm used for that is essentially the same as
the one QEMU uses.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
VFIO AP has a limitation on a single device per domain, however, when
commit 11708641 added the support for vfio-ap, check for this limitation
was performed as part of the post parse code. Generally, checks like that
should be performed within the driver's validation callback to eliminate
any slight chance of failing in post parse, which could potentially
result in the domain XML config vanishing.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Since we'll need to validate other models apart from VFIO PCI too,
having a helper for each model should keep the code base cleaner.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
There's a lot of stuff going on in src/conf/nodedev_conf which is
sometimes not directly related to config and we're not really consistent
with putting only parser/formatter related stuff here, e.g. like we do
for domains. So, let's start simply by adding a new module
node_device_util containing some of the helpers. Unfortunately, even
though these helpers tend to open a secondary driver connection and would
be much therefore better suited as a nodedev driver module, we can't do
that without pulling headers from the driver into conf/ and that's wrong
because we want conf/ to stay driver-agnostic.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
All of the ones being removed are pulled in by internal.h. The only
exception is sanlock which expects the application to include <stdint.h>
before sanlock's headers, because sanlock prototypes use fixed width
int, but they don't include stdint.h themselves, so we have to leave
that one in place.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
It doesn't really make sense for us to have stdlib.h and string.h but
not stdio.h in the internal.h header.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
From time to time it's handy to jump directly to a function prototype in
a header. However, generating tags for headers is disabled by default in
ctags, let's enable it by using --c-kinds=+p.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Since we're not saving the platform-specific data into a cache, we're
not going to populate the structure, which in turn will cause a crash
upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
Ultimately, we should start caching this data along with host-specific
capabilities like NUMA and SELinux stuff into a separate cache, but for
the time being, this is a semi-proper fix for a potential crash.
Backtrace (requires libvirtd restart to load qemu caps from cache):
#0 qemuGetSEVInfoToParams
#1 qemuNodeGetSEVInfo
#2 virNodeGetSEVInfo
#3 remoteDispatchNodeGetSevInfo
#4 remoteDispatchNodeGetSevInfoHelper
#5 virNetServerProgramDispatchCall
#6 virNetServerProgramDispatch
#7 virNetServerProcessMsg
#8 virNetServerHandleJob
#9 virThreadPoolWorker
#10 virThreadHelper
https: //bugzilla.redhat.com/show_bug.cgi?id=1612009
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
So the procedure to detect SEV support works like this:
1) we detect that sev-guest is among the QOM types and set the cap flag
2) we probe the monitor for SEV support
- this is tricky, because QEMU with compiled SEV support will always
report -object sev-guest and query-sev-capabilities command, that
however doesn't mean SEV is supported
3) depending on what the monitor returned, we either keep or clear the
capability flag for SEV
Commit a349c6c21c added an explicit check for "GenericError" in the
monitor reply to prevent libvirtd to spam logs about missing
'query-sev-capabilities' command. At the same time though, it returned
success in this case which means that we didn't clear the capability
flag afterwards and happily formatted SEV into qemuCaps. Therefore,
adjust all the relevant callers to handle -1 on errors, 0 on SEV being
unsupported and 1 on SEV being supported.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Keep with the recent effort of replacing as many explicit *Free
functions with their automatic equivalents.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
In order to test SEV we need real QEMU capabilities. Ideally, this would
be tested with -latest capabilities, however, our capabilities are
currently tied to Intel HW, even the 2.12.0 containing SEV were edited by
hand, so we can only use that one for now, as splitting the capabilities
according to the vendor is a refactor for another day. The need for real
capabilities comes from the extended SEV platform data (PDH, cbitpos,
etc.) we'll need to cache/parse.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Caused by commit f7d0663d49. The problem is missing libnl library on
these platforms, so the VIR_DEFINE_AUTOPTR_FUNC has to be compiled in
conditionally.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commits 7b706f33ac and 4acb7887e4 introduced some compound type *Free
wrappers in order to use them with VIR_DEFINE_AUTOPTR_FUNC. However,
since those were not used in the code right away, Clang complained about
unused functions (static ones that are defined by the macro above).
This patch puts the defined functions in use.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Technically, it was never used ever since commit @f4d06ca8fd9 introduced
it, but the fact that we called VIR_FREE on it was enough for Clang to
never complain about it.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit d48813e8 made sure we wouldn't get one for i440fx, but not for Q35
machine type. If the primary video didn't get the assumed 0:0:1.0 PCI
address, the evaluation then failed with: "Cannot automatically add a
new PCI bus for a device with connect flags 00"
https://bugzilla.redhat.com/show_bug.cgi?id=1609087
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Historically, we've always enabled an emulated video device every time we
see that graphics should be supported with a guest. With the appearance
of mediated devices which can support QEMU's vfio-display capability,
users might want to use such a device as the only video device.
Therefore introduce a new, effectively a 'disable', type for video
device.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Currently it reads:
Refer MDEV to create a mediated device on the host
...even though it resembles English, it's not a proper English.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Since QEMU 2.12, QEMU understands a new vfio-pci device option 'display'
which can be used to turn on display capabilities on vgpu-enabled
mediated devices, IOW emulated GPU devices like QXL will no longer be
needed with vgpu-enable mdevs.
QEMU defaults to 'auto' for the 'display' attribute, which is not
foolproof, so we need to play it safe here and default to display='off'
if this attribute wasn't provided in the XML explicitly.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
QEMU 2.12 introduced a new type of display for mediated devices using
vfio-pci backend which allows a mediated device to be used as a VGA
compatible device as an alternative to an emulated video device. QEMU
exposes this feature via a vfio device property 'display' with supported
values 'on/off/auto' (libvirt will default to 'off').
This patch adds the necessary bits to domain config handling in order to
expose this feature. Since there's no convenient way for libvirt to come
up with usable defaults for the display setting, simply because libvirt
is not able to figure out which of the display implementations - dma-buf
which requires OpenGL support vs vfio regions which doesn't need OpenGL
(works with OpenGL enabled too) - the underlying mdev uses.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The exit path is the same for both success and failure, so the label
should be called cleanup.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A simple helper which will loop through all the graphics elements and
checks whether at least one of them enables OpenGL support, either by
containing <gl enable='yes'/> or being of type 'egl-headless'.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'.
This patch introduces the necessary capability.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since 2.10 QEMU supports a new display type egl-headless which uses the
drm nodes for OpenGL rendering copying back the rendered bits back to
QEMU into a dma-buf which can be accessed by standard "display" apps
like VNC or SPICE. Although this display type can be used on its own,
for any practical use case it makes sense to pair it with either VNC or
SPICE display. The clear benefit of this display is that VNC gains
OpenGL support, which it natively doesn't have, and SPICE gains remote
OpenGL support (native OpenGL support only works locally through a UNIX
socket, i.e. listen type=socket/none).
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Since QEMU 2.10, it's possible to use a new type of display -
egl-headless which uses drm nodes to provide OpenGL support. This patch
adds a capability for that. However, since QEMU doesn't provide a QMP
command to probe it, we have to base the capability on specific QEMU
version.
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The original capabilities didn't include a patched kernel for spectre,
SPICE gl support and had xen support enabled which we already have
dropped.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
There wasn't an explicit type case to the video type enum in
qemuDomainDeviceDefValidateVideo, _TYPE_GOP was also missing from the
switch.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Move the video post parse bits into a separate helper as the logic is
going to be extended in the future.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Future patches rely on the ability to reset the contents of the
virDomainVideoDef structure rather than re-allocating it.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since 133fb140 moved the validation of a video device into a separate
function, the code handling PCI slot assignment for video devices has
been the same for both the primary device and the secondary devices.
Let's merge these and thus handle all the devices within the existing
'for' loop.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
QEMU uses a shorthand '-sdl' which maps to '-display sdl'. However, if
there are any options to be passed to SDL, the full command version must
be used. Everything seemingly worked for us until commit 5038b30043
introduced OpenGL support for SDL and added ',gl=on/off' option which as
mentioned above could have never worked with the shorthand version of
the command. Indeed starting a domain with an SDL display and OpenGL
enabled, QEMU produces a rather cryptic error:
-sdl: Could not open 'gl=on': No such file or directory
This patch provides fixes to both the SDL cmdline generation and the
test suite.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Adding the 'default' case to our enum-typecasted switches is the current
safety trend, so add it here for mdevs too.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It should be the command line helper who takes care of the iteration
rather than the caller.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It's pointless to check the same thing multiple times.
Fix the indentation along the way too.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If measurement retrieval fails we'd forget to call ExitMonitor to unlock
the monitor.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reported-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Since it's being called with QEMU_ASYNC_JOB_NONE which is what
qemuDomainObjEnterMonitor is going to use with the internal helper,
let's use that one instead.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
We only formatted the <sev> element when QEMU supported the feature when
in fact we should always format the element to make clear that libvirt
knows about the feature and the fact whether it is or isn't supported
depends on QEMU version, in other words if QEMU doesn't support the
feature we're going to format the following into the domain capabilities
XML:
<sev supported='no'/>
This patch also adjusts the RNG schema accordingly in order to reflect
the proposed change.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the introduction of log tuning capabilities to virt-admin by
@06b91785, this has been a much needed missing improvement on the way to
deprecate the global 'log_level'.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When applying the log filters, one has to define the more specific
filters before the generic ones, because the first filter that matches
will be applied. However, we've been missing this information in the
config, so it always has been a trial-error scenario figuring out that
e.g. '4:util 1:util.pci' doesn't actually enable verbose logging on the
src/util/virpci.c module because 4:util will be matched first.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit b4c2ac8d56 made a false assumption that IOMMU support necessary
for an mdev device to be assigned to a VM. Unlike direct PCI assignment,
IOMMU support is not needed for mediated devices, as the physical parent
device provides the isolation, therefore, simply checking for VFIO
presence is enough to successfully start a VM.
Luckily, this issue is not serious, since as of yet, libvirt mandates
mdevs to be pre-created prior to a domain's launch - if it is,
everything does work smoothly even with IOMMU disabled, because the
parent device will ensure the iommu groups we try to access exist.
However, if there are *no* IOMMU groups yet, thus no mdev exists yet, one
would see the following error:
"unsupported configuration: Mediated host device assignment requires VFIO
support"
The error msg above is simply wrong and doesn't even reflect the IOMMU
reality, so after applying this patch one would rather see the following
error in such case instead:
"device not found: mediated device '<UUID>' not found"
Signed-off-by: Erik Skultety <eskultet@redhat.com>
What one currently gets is:
failed to read '/sys/bus/mdev/devices/<UUID>/mdev_type/device_api': No
such file or directory
This indicates that something is missing within the device's sysfs tree
which likely might be not be the case here because the device simply
doesn't exist yet. So, when creating our internal mdev obj, let's check
whether the device exists first prior to trying to verify the
user-provided model within domain XML.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When commit 3545cbef moved the sysfs attribute reading logic from
_udev.c module to virmdev.c, it had to replace our udev read wrappers
with the ones available from virfile.c. The problem is that the original
logic worked correctly with udev read wrappers which don't return an
error code for a missing attribute, virfile.c readers however - not so
much. Therefore add another parameter to the macro, so we can again
accept the fact that optional attributes may be missing.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Fix this common typo and assign a value rather than implicitly
type-casted comparison result. Introduced by commit b6a264e855.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commits f83c7c88 and 6eb1f2b9 broke the build on FreeBSD and OSX because
of symbols being undefined for those platforms.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Just like SRIOV, a PCI device is only capable of the mediated devices
framework when it's bound to the vendor native driver, thus if a driver
change occurs, e.g. vendor_native->vfio, we need to refresh some of the
device's capabilities to reflect the reality, mdev included.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Suggested-by: Wu Zongyong <cordius.wu@huawei.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Now that we have all the building blocks in place, switch the nodedev
driver to use the "new" virMediatedDeviceType type instead of the "old"
virNodeDevCapMdevType one.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
These are not necessary anymore, since these are going to be shadowed by
the helpers provided by util/virmdev.c module.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This is a replacement for the existing udevPCIGetMdevTypesCap which is
static to the udev backend. This simple helper constructs the sysfs path
from the device's base path for each mdev type and queries the
corresponding attributes of that type.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This should serve as a replacement for the existing udevFillMdevType
which is responsible for fetching the device type's attributes from the
sysfs interface. The problem with the existing solution is that it's
tied to the udev backend.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This is later going to replace the existing virNodeDevCapMdevType, since:
1) it's going to couple related stuff in a single module
2) util is supposed to contain helpers that are widely accessible across
the whole repository.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety