Test that the vcpu entity selection code works properly

Add code that validates user's selection of cores and then uses the
existing code to plug in the vCPU.

Add a simple virsh command handler which makes use of the new API.

Similarly to domainSetGuestVcpus this commit adds API which allows to
modify state of individual vcpus rather than just setting the count.

This allows to enable CPUs in specific guest NUMA nodes to achieve any
necessary configuration.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

With that users could access files outside /dev/shm.  That itself
isn't a security problem, but might cause some errors we want to
avoid.  So let's forbid slashes as we do with domain and volume names
and also mention that in the schema.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1395496Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Compile the storage driver into modules rather than by compiling all
files together. All modules are still linked together statically.

Add APIs that allow to dynamically register driver backends so that the
list of available drivers does not need to be known during compile time.

This will allow us to modularize the storage driver on runtime.

Pass the registration function name to virDriverLoadModule so that we
can later call specific functions if necessary (e.g. for testing
purposes). This gets rid of the rather ugly automatic name generator and
unifies the code to load/initialize the modules.

It's also clear which registration function gets called.

Split the convoluted driver loader function into simpler parts which
will potentially allow reuse.

Refactors of the test resulted into the second argument of the 'TEST'
macro to be unused. Drop them.

The XML2XML test should work properly even if the storage backend is
disabled, since it does not use it.

We'd print status for the 'dir' backend instead of the correct one.

The niothreadids struct field is size_t, so must use %zu not %lu
with printf. While they're identical on some platforms, on others
they are different, causing warnings

conf/domain_conf.c: In function 'virDomainDefCheckABIStabilityFlags':
conf/domain_conf.c:19575:26: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}' [-Werror=format=]
                        _("Target domain iothreads count %lu does not "
                          ^

conf/domain_conf.c: In function 'virDomainDefFormatInternal':
conf/domain_conf.c:23915:46: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Werror=format=]
         virBufferAsprintf(buf, "<iothreads>%lu</iothreads>\n",
                                              ^
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This follows the same check for disk, because we cannot remove iothread
if it's used by disk or by controller.  It could lead to crashing QEMU.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If virDomainDelIOThread API was called with VIR_DOMAIN_AFFECT_LIVE
and VIR_DOMAIN_AFFECT_CONFIG and both XML were already a different
it could result in removing iothread from config XML even if there
was a disk using that iothread.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This will ensure that IOThreads are properly validated while
a domain is defined.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The situation covered by the removed code will not ever happen.
This code is called only while starting a new QEMU process where
the capabilities where already checked and while attaching to
existing QEMU process where we don't even detect the iothreads.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The utils code should stay separated from other code (except for very
well justified cases). Unfortunately commit 272769be
made it trivial to break the separation (and not get slapped by the
syntax-check rule) by adding -I src/conf to the CFLAGS for utils.

Remove this shortcut and except the two offenders from the syntax check
so that the codebase can be kept separated.

The comment was actually wrong as
https://www.freedesktop.org/software/systemd/man/udev_new.html#
mentions that on failure NULL is returned.  Also the same return value
is checked in src/interface/interface_backend_udev.c already.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

QEMU 2.9.0 is not released yet but it's close to its release and
we need this data to implement new features that will be in
that release.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The old data was generated from not released QEMU.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When enabling virgl, qemu opens /dev/dri/render*. So far, we are
not allowing that in devices CGroup nor creating the file in
domain's namespace and thus requiring users to set the paths in
qemu.conf. This, however, is suboptimal as it allows access to
ALL qemu processes even those which don't have virgl configured.
Now that we have a way to specify render node that qemu will use
we can be more cautious and enable just that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far, qemuDomainGetHostdevPath has no knowledge of the reasong
it is called and thus reports /dev/vfio/vfio for every VFIO
backed device. This is suboptimal, as we want it to:

a) report /dev/vfio/vfio on every addition or domain startup
b) report /dev/vfio/vfio only on last VFIO device being unplugged

If a domain is being stopped then namespace and CGroup die with
it so no need to worry about that. I mean, even when a domain
that's exiting has more than one VFIO devices assigned to it,
this function does not clean /dev/vfio/vfio in CGroup nor in the
namespace. But that doesn't matter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

So far, we are allowing /dev/vfio/vfio in the devices cgroup
unconditionally (and creating it in the namespace too). Even if
domain has no hostdev assignment configured. This is potential
security hole. Therefore, when starting the domain (or
hotplugging a hostdev) create & allow /dev/vfio/vfio too (if
needed).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Since these two functions are nearly identical (with
qemuSetupHostdevCgroup actually calling virCgroupAllowDevicePath)
we can have one function call the other and thus de-duplicate
some code.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

There's no need for this function. Currently it is passed as a
callback to virSCSIVHostDeviceFileIterate(). However, SCSI host
devices have just one file path. Therefore we can mimic approach
used in qemuDomainGetHostdevPath() to get path and call
virCgroupAllowDevicePath() directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

There's no need for this function. Currently it is passed as a
callback to virSCSIDeviceFileIterate(). However, SCSI devices
have just one file path. Therefore we can mimic approach used in
qemuDomainGetHostdevPath() to get path and call
virCgroupAllowDevicePath() directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

There's no need for this function. Currently it is passed as a
callback to virUSBDeviceFileIterate(). However, USB devices have
just one file path. Therefore we can mimic approach used in
qemuDomainGetHostdevPath() to get path and call
virCgroupAllowDevicePath() directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add a test that allows providing the parent fabric_wwn in the input XML
in order to create the vHBA.

This also fixes a mixed setting of the fabric_wwn field from the read
test driver XML strings.