Remove the "luks" distinction as the code is about to become more
generic and be able to support qcow encryption as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move generation of secretPath to storageBackendGenerateSecretData
and simplify a bit since we know vol->target.encryption is set plus
we have a local @enc.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than having storageBackendCreateQemuImgCheckEncryption
perform the virStorageGenerateQcowEncryption, let's just do that
earlier during storageBackendCreateQemuImg so that the check
helper is just a check helper rather doing something different
based on whether the format is qcow[2] or raw based encryption.

This fixes an issue in the storageBackendResizeQemuImg processing
for qcow encryption where if a secret was not available for a
volume, a new secret will not be generated and instead an error
message will be generated.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rename to storageBackendCreateQemuImgOpts - which is what it's doing.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id 'a48c7141' altered the logic a bit and didn't
remove an unnecessary check as info.encryption is true when
vol->target.encryption != NULL, so if we enter the if segment
with info.format == VIR_STORAGE_FILE_RAW && vol->target.encryption
!= NULL, then there's no way info.encryption could be false.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove the != NULL checks, use !! for setting info.encryption.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Perform some code cleanup in areas that are about to be altered.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Support OpenGL when using SDL backend via -sdl,gl=on. Add associated
tests.

NB: Usage of DO_TEST_CAPS_LATEST in qemuxml2argv doesn't work in
this case because -sdl gl is not introspectable.
Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Support OpenGL acceleration capability when using SDL graphics.
Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Support OpenGL accelerated rendering when using SDL graphics in the
domain config. Add associated test and documentation.
Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Create a function called `qemuBuildGraphicsSDLCommandLine` which is
called from qemuBuildGraphicsCommandLine.
Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It only accepts a virObjecLockable, not a virObjecRWLockable
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

libxlDoDomainSave() is used in both the save and managedsave code
paths but was unconditionally setting hasManagedSave to true on
success. As a result, undefine would fail after a non-managed
save/restore operation. E.g.

virsh define; virsh start
virsh save; virsh restore
virsh shutdown
virsh undefine
error: Refusing to undefine while domain managed save image exists

Modify libxlDoDomainSave() to take an additional parameter to
specify managed vs non-managed save, and change callers to use it.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Parser assumed extra was always present when root was specified.
Fixed by handling root and extra separately.
Signed-off-by: NFilip Alac <filipalac@gmail.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Generates the QEMU command line for the vfio-ccw device.

Adds various functionality testing for vfio-ccw in libvirt:

1. Generation of QEMU command line from domain xml file
2. Generation of dump xml from domain xml file
3. Checks duplicate/invalid addresses for vfio-ccw devices.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Introduces the vfio-ccw model for mediated devices and prime vfio-ccw
devices such that CCW address will be generated.

Alters the qemuxml2xmltest for testing a basic mdev device using vfio-ccw.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Add the function virHostdevIsMdevDevice() which detects whether a
hostdev is a mediated device or not. Also, replace all existing
conditionals.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Let us introduce the capability vfio-ccw for supporting the basic
channel I/O passthrough, which have been introduced in QEMU 2.10. The
current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390)
as the target device.

Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED
for virtual-css-bridge. This capability is based on the
cssid-unrestricted property which exists if QEMU no longer enforces
cssid restrictions based on ccw device types.

Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so
that we are able to probe for the cssid-unrestriced property to make
sure the devices are visible to non-mcss-e enabled guests.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge
and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments
which identify support for ccw devices.

The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7.
The QEMU_CAPS_CCW capability is based on the existence of the QEMU type.

Let us also add the capability QEMU_CAPS_CCW to the tests which
require support for ccw devices.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Ditch the use of gnulib's digest functions in favor of GnuTLS,
which might be more likely to get FIPS-certified.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Do not rely on gnulib's MD5_DIGEST_SIZE from md5.h.

Include vircrypto.h and use VIR_CRYPTO_HASH_SIZE_MD5.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Instead of using md5_buffer from gnulib directly.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

A function that keeps the hash in binary form instead of converting
it to human-readable hexadecimal form.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The callers needing to know the size of the resulting digest
rely on _DIGEST_SIZE constants from gnulib.

Introduce VIR_CRYPTO_HASH_SIZE_ constants to remove the dependency.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1480668

QEMU has this new feature memory-backend-file.discard-data=yes
which is a nifty optimization. Basically, when qemu is quitting
or on memory hotplug it calls munmap() and close() on the file
that is backing the memory. However, this does not mean kernel
won't stop touching that part of memory. It still might. With
this feature enabled we tell kernel: "we don't need this memory
nor data stored in it". This makes kernel drop the memory
immediately without trying to sync memory with the mapped file.

Unfortunately, this cannot be turned on by default because we
can't be sure when users really don't care about what happens to
data after qemu dies. So it has to be opt-in. As usual, there are
three places where one can configure memory attributes. This
patch adds the feature to all of them.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU has possibility to call madvise(.., MADV_REMOVE) in some
cases. Expose this feature to users by new element/attribute
discard.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

At the same time convert the code to use virXMLFormatElement.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This capability tracks if qemu has "qom-list-properties" monitor
command.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that we've gotten rid of misleading names we can introduce
qemuMonitorGetObjectProps() function which queries -object
properties. Again, some parts of code can be reused.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The code that processes list of device properties is going to be
reused. Therefore put it into a separate function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Last functions using it were moved to virfile.c in commit <bfe7721d>.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Added by commit 61674cc1, but we have started using
set_nonblocking_flag from gnulib in commit da3c4714Signed-off-by: NJán Tomko <jtomko@redhat.com>

The <memoryBacking><locked/></memoryBacking> element will now pass the
wired (-S) flag to the bhyve command.
Signed-off-by: NFabian Freyer <fabian.freyer@physik.tu-berlin.de>
Reviewed-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>

Strongly recommend against use of the log_levels setting since it
creates overly verbose logs and has a serious performance impact.

Describe the log filter syntax better and mention use of shell
glob syntax. Also provide more realistic example of good settings
to use. The libvirtd example is biased towards QEMU, but when the
drivers split off each daemon can get its own more appropriate
example.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Rather than specialcasing handling of the '*' character, use fnmatch()
to get normal shell wildcard syntax, as described in 'man glob(7)'.

To get an indication of the performance impact of using globs instead
of plain string matches, a test program was written. The list of all
260 log categories was extracted from the source. Then a typical log
filters setup was picked by creating an array of the strings "qemu",
"security", "util", "cgroup", "event", "object". Every filter string
was matched against every log category. Timing information showed that
using strstr() this took 8 microseconds, while fnmatch() took 114
microseconds.

IOW, fnmatch is 14 times slower than our existing strstr check. These
numbers show a worst case scenario that will never be hit, because it
is rare that every log category would have data output. The log category
matches are cached, so each category is only checked once no matter how
many log statements are emitted. IOW despite being slower, this will
be lost in the noise and have no consequence on real world logging
performance.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>