Extract virPCIGetMdevTypes from PCI as virMediatedDeviceGetMdevTypes
into mdev for later reuse.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The nodedev schema defines that a mdev_types capability must have
one or more type elements. The XML parsing and the format allows to
accept and to write mdev_types capability without any type element.
This patches fixes this.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Adds documentation for QEMU 9pfs 'fmode' and 'dmode' options.
Signed-off-by: Brian Turek <brian.turek@gmail.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add logic to validate and then pass through 'fmode' and 'dmode' to the
QEMU call.
Signed-off-by: Brian Turek <brian.turek@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Expose QEMU's 9pfs 'fmode' and 'dmode' options via attributes on the
'filesystem' node in the domain XML. These options control the creation
mode of files and directories, respectively, when using
accessmode=mapped.
Signed-off-by: Brian Turek <brian.turek@gmail.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QEMU 9pfs 'fmode' and 'dmode' options have existed since QEMU 2.10.
Probe QEMU's command line set to check whether these options are
available, and if yes, enable this new QEMU_CAPS_FSDEV_CREATEMODE
capability on libvirt side.
Signed-off-by: Brian Turek <brian.turek@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Aleksandr Alekseev <alexander.alekseev@virtuozzo.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Aleksandr Alekseev <alexander.alekseev@virtuozzo.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Aleksandr Alekseev <alexander.alekseev@virtuozzo.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Function to compare CPU on 64-bits PowerPC is ignoring the flag to avoid failure
in case of CPUs (host and guest) are incompatible. Basically, the function is
returning -1 even if it is set to continue.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Setting SYNC_TIME=1 does not work on autostarted guests.
See https://bugzilla.redhat.com/show_bug.cgi?id=1555398.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit f00cde7f11 changed order of mount arguments in
virStorageBackendFileSystemMountGlusterArgs() and introduced per-OS
mount options and new test data. Old test data was left unmodified with
prior order of arguments. That causes a test failure on all OSes but
Linux and FreeBSD, i.e. on macOS:
15) Storage Pool XML-2-argv pool-netfs-gluster
...
In
'/Users/roolebo/dev/libvirt/tests/storagepoolxml2argvdata/pool-netfs-gluster.argv':
Offset 39
Expect [-o direct-io-mode=1 /mnt/gluster]
Actual [/mnt/gluster -o direct-io-mode=1]
Fixes: f00cde7f11 ("storage: Add default mount options for fs/netfs storage pools")
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In general, it has little sense to use Linux pci mock on macOS but
virPCIDeviceAddressGetIOMMUGroupNum() is relying on the filesystem
layout mocked by virpcimock. And all tests that rely on correct
execution of virPCIDeviceAddressGetIOMMUGroupNum() fail.
The change fixes qemuhotplugtest, qemumemlocktest and qemuxml2xmltest.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
real_close() is not inialized by the first invocation of close(). That
causes an issue when the mock is used before others and a call of
real_close() results in a jump to NULL pointer.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that every caller to copyPlacement doesn't pass absolute path there
is no need to have a condition to handle that case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The old code passed an absolute path to virCgroupNewFromParent() which
is not necessary. The code can take the current placement of parent
cgroup and append a relative path.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use virStringSplit() to get the list of directories needed to be
created. This improves readability of the code and stops passing
absolute path to virCgroupNewFromParent().
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently this task is done by virCgroupCopyPlacement when the @path
starts with "/".
virCgroupNew is always called with @path starting with "/" and there is
no parent to copy path from. To make it obvious what the code is doing
introduce new helper.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function is relevant only with cgroups v1 where it creates
hierarchy for controllers that are not managed by systemd. PID is used
to detect a placement of current process but in this situation we are
building the hierarchy for already known placement.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current code uses virCgroupNew() as a single point of entry and
calls into virCgroupDetect() as well. Both have logic for several paths
which is difficult to figure out.
Extract the actually used code path from the two functions to make
it obvious what's happening in this case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current code uses virCgroupNew() as a single point of entry and
calls into virCgroupDetect() as well. Both have logic for several paths
which is difficult to figure out.
Extract the actually used code path from the two functions to make
it obvious what's happening in this case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It is only used for debug and error purposes which can be easily
replaced by @placement.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With cgroups v2 working with controllers is a bit more complicated then
with cgroups v1 where the controller had to be mounted.
There are two files, cgroups.controllers and cgroup.subtree_control.
The file cgroup.controllers lists all controllers enabled in the current
cgroup and cgroups.subtree_control, as the name suggest, controls which
controllers are enabled for a subtree of cgroups.
Now the issue here is that the current code doesn't make any difference
if the @parent variable is NULL or not because ../cgroup.subtree_control
will list the same controllers as ./cgroup.controllers.
The whole point of the @parent variable is when we are building the
cgroup topology ourselves without systemd help we need to detect which
controllers are enabled in the parent cgroup in order to enable them for
the current cgroup as well and for that we need to check
cgroup.controllers of the parent group.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When libvirtd starts a VM it internally stores a path to the main
cgroup. When we restart libvirtd we should get to the same state.
When we start a VM on host with systemd the cgroup is created for us and
the process is already placed into that cgroup and we detect the path
created by systemd using /proc/$PID/cgroup. After that we create
sub-cgroups and move all threads there.
Once libvirtd is restarted we again detect the cgroup path using
/proc/$PID/cgroup, but in this case we will get a different path because
the main thread was moved to a "emulator" cgroup.
Instead of ignoring the "emulator" directory when validating cgroups
remove it completely when detecting cgroup otherwise cgroups will not
work properly when libvirtd is restarted.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With cgroups v2 the file cgroup.procs will never be empty if threading
is enabled as it will always have ID of all processes even if all
threads of the processes are moved to sub-cgroups. If that happens the
file cgroup.threads will be empty.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All other helper processes are moved to cgroup with QEMU emulator
thread as we keep the root VM cgroup without any processes. This
assumption is validated in qemuRestoreCgroupState() which is called
when libvirtd is restarted and reconnected to all running VMs.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In both cases priv->cgroup will always be NULL because it is called
before the QEMU process is started and cgroups are configured.
In qemuProcessLaunch() the call order is following:
qemuExtDevicesStart()
...
virCommandRun()
...
qemuSetupCgroup()
where qemuDBusStart() is called from qemuExtDevicesStart() but we
cgroups are created in qemuSetupCgroup().
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This should have been included with the upgrade to openwsman 2.6.3.
Signed-off-by: Matt Coleman <matt@datto.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This places it next to existing related functions.
Signed-off-by: Matt Coleman <matt@datto.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
* use the same section comment in the header and code
* place the items in the same relative location within the .h and .c
* one parameter per line for multiline function definitions
Signed-off-by: Matt Coleman <matt@datto.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After converting all DIR* to g_autoptr(DIR), many cleanup: labels
ended up just having "return ret", and every place that set ret would
just immediately goto cleanup. Remove the cleanup label and its
return, and just return the set value immediately, thus eliminating
the need for the return variable itself.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Once the DIR* in virPCIGetName() was made g_autoptr, the cleanup:
label just had a "return ret;", but the rest of the function was more
compilcated than it needed to be, doing funky things with the value of
ret inside multi-level conditionals and a while loop that might exit
early via a break with ret == 0 or exit early via a goto cleanup with
ret == -1.
It really didn't need to be nearly as complicated. After doing the
trivial replacements of "goto cleanup" with appropriate direct
returns, it became obvious that:
1) the outermost level of the nested conditional at the end of the
function ("if (ret < 0)") was now redundant, since ret is now
*always* < 0 by that point (otherwise the function has returned).
2) by switching the sense of the next level of the conditional (making
it "if (!physPortID)", the "else" (which is now just "return 0;"
becomes the "if", and the new "else" no longer needs to be inside
the conditional.
3) the value of firstEntryName can be moved into *netname with
g_steal_pointer()
Once that is all done, ret is no longer used and can be removed.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
