The 'pvspinlock' feature is x86 only. The "<pvspinlock/>" declaration
will always have a value 'on' or 'off', and both will break QEMU when
launching non-x86 guests. This is the error message for
"<pvspinlock state='on'/>" when running a ppc64 guest:

qemu-kvm: Expected key=value format, found +kvm_pv_unhalt

A similar error message is thrown for "<pvspinlock state='off'/>".

This patch prevents non-x86 guests from launching with any
pvspinlock setting with a more informative error message:

error: unsupported configuration: The 'pvspinlock' feature is not
supported for architecture 'ppc64' or machine type 'pseries'
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The "<apic/>" feature, although it's available only for x86 guests,
can be declared in the domain XML of other archs without errors.
But setting its 'eoi' attribute will break QEMU. For "<apic eoi='on'/>",
in a ppc64 guest:

qemu-kvm: Expected key=value format, found +kvm_pv_eoi

A similar error happens with eoi='off'.

One can argue that it's better to simply forbid launching non-x86
guests with "<apic/>" declared in the XML - it is a feature that
the architecture doesn't support and this would make it clearer
about it. This is sensible, but there are non-x86 guests that are
running with "<apic/>" declared in the domain (and A LOT of guests
running with "<acpi/>" for that matter, probably reminiscent of x86
templates that were reused for other archs) that will stop working if we
go this route.

A more subtle approach is to detect if the 'eoi' element is being set
for non-x86 guests and warn the user about it with a better error
message than the one QEMU provides. This is the new error message
when any value is set for the 'eoi' element in a ppc64 XML:

error: unsupported configuration: The 'eoi' attribute of the 'apic'
feature is not supported for architecture 'ppc64' or machine type
'pseries'.

https://bugzilla.redhat.com/show_bug.cgi?id=1236440Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Helper processes may have their state migrated with QEMU data stream
thanks to the QEMU "dbus-vmstate".

libvirt maintains the list of helpers to be migrated. The
"dbus-vmstate" is added when required, and given the list of helper
Ids that must be migrated, on save & load sides.

See also:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/dbus-vmstate.rstSigned-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This avoids trying to start a dbus-daemon when its already running.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This code was based on a per-helper instance and peer-to-peer
connections. The code that landed in qemu master for v5.0 is relying
on a single instance and DBus bus.

Instead of trying to adapt the existing dbus-vmstate code, let's
remove it and resubmit. That should make reviewing easier.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Introduce qemuBlockStorageSourceGetCookieString which does the
concatenation so that we can reuse it later.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Using the 'uuid' element for ppc64 NVDIMM memory added in the
previous patch, use it in qemuBuildMemoryDeviceStr() to pass
it over to QEMU.

Another ppc64 restriction is the necessity of a mem->labelsize,
given than ppc64 only support label-area backed NVDIMMs.

Finally, we don't want ppc64 NVDIMMs to align up due to the
high risk of going beyond the end of file with a 256MiB
increment that the user didn't predict. Align it down
instead. If target size is less than the minimum of
256MiB + labelsize, error out since QEMU will error out
if we attempt to round it up to the minimum.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The @devPath variable is not modifiable. It merely just points to
string containing path where private devtmpfs is being
constructed. Make it const so it doesn't look weird that it's not
freed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

If building namespace fails somewhere in the middle (that is some
files exists under devMountsSavePath[i]), then plain rmdir() is
not enough to remove dir. Umount the temp location and use
virFileDeleteTree() to remove the directory.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

The virFileMakePathWithMode() which is our recursive version of
mkdir() fails, it simply just returns a negative value with errno
set. No error is reported (as compared to virFileTouch() for
instance).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

Introduce qemuBlockStorageSourceNeedsStorageSliceLayer which will hold
the decision logic and fix all places that open-code it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In one of my previous commits I've introduced code that creates
all devices for given (possible) multipath target. But I've made
a mistake there - the code accesses 'next->path' without checking
if the disk source is local. Note that the 'next->path' is
NULL/doesn't make sense for VIR_STORAGE_TYPE_NVME.

Fixes: a30078cb
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1814947Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

So far, when using the qemu:///embed driver, management
applications can't chose whether they want to register their
domains in machined or not. While having that option is certainly
desired, it will require more work. What we can do meanwhile is
to generate names that include part of hash of the root
directory. This is to ensure that if two applications using
different roots but the same domain name (and ID) start the
domain no clashing name for machined is generated.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Starting a commit job will require disabling bitmaps in the base image
so that they are not dirtied by the commit job. We need to store a list
of the bitmaps so that we can later re-enable them.

Add a field and status XML handling code as well as a test.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

I'll be adding more fields to care about so splitting the code out will
be better long-term.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

I'll be adding more fields to care about so splitting the code out will
be better long-term.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NGaurav Agrawal <agrawalgaurav@gnome.org>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The logic for querying hotpluggable CPUs needs to sort the list
of CPUs returned by QEMU. Unfortunately our sorting method failed
to use the die_id field, so CPUs were not correctly sorted.

This is seen when configuring a guest with partially populated
CPUs

  <vcpu placement='static' current='1'>16</vcpu>
  <cpu...>
    <topology sockets='4' dies='2' cores='1' threads='2'/>
  </cpu>

Then trying to start it would fail:

  # virsh -c qemu:///system start demo
  error: Failed to start domain demo
  error: internal error: qemu didn't report thread id for vcpu '0'
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

QEMU's curl driver requires the cookies concatenated and allows themi to
be passed in via a secret. Prepare the value for the secret and encrypt
it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The http cookies can have potentially sensitive values and thus should
not be leaked into the command line. This means that we'll need to
instantiate a 'secret' object in qemu to pass the value encrypted.

This patch adds infrastructure for storing of the alias in the status
XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Ensure that the new fields are allowed only when -blockdev is used or
when they are in the detected part of the backing chain where qemu will
handle them internally.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Originally there was only the secret for authentication so we didn't use
any suffix to tell it apart. With the introduction of encryption we
added a 'luks' suffix for the encryption secrets. Since encryption is
really generic and authentication is not the only secret modify the
aliases for the secrets to better describe what they are used for.

This is possible as we store the disk secrets in the status XML thus
only new machines will use the new secrets.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Replace qemuDomainGetSecretAESAlias by the new function so that we can
reuse qemuDomainSecretAESSetupFromSecret also for setting up other kinds
of objects.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Currently we don't have infrastructure to remember the secret aliases
for hostdevs. Since an upcoming patch is going to change aliases for
the disks, initialize the iscsi hostdevs separately so that we can keep
the alias. At the same time let's use qemuAliasForSecret instead of
qemuDomainGetSecretAESAlias when unplugging the iscsi hostdev.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In order to be able to change the function generating the alias and thus
also the aliases itself, we must hardcode the old format for the case of
upgrading form libvirt which didn't record them in the status XML yet.

Note that this code path is tested by
'tests/qemustatusxml2xmldata/disk-secinfo-upgrade-in.xml'
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The naming of the variables was tied to what they are used for not what
the alias represents. Since we'll need to use some of the aliases for
another type of secrets fix the name so that it makes sense.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Replace it by a direct call to qemuDomainSecretAESSetupFromSecret.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Split out the lookup of the secret from the secret driver into
qemuDomainSecretAESSetupFromSecret so that we can also instantiate
secret objects in qemu with data from other sources.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Rather than passing in an empty qemuDomainSecretInfoPtr allocate it
in this function and return it. This is done by absorbing the check from
qemuDomainSecretInfoNew and removing the internals of
qemuDomainSecretInfoNew.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use g_autofree for the ciphertext and init vector as they are not
secret and thus don't have to be cleared and use g_new0 to allocate the
iv for parity.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Using a double pointer prevents the function from being used as the
automatic cleanup function for the given type.

Remove the double pointer use by replacing the calls with
g_clear_pointer which ensures that the pointer is cleared.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

If a disk has persistent reservations enabled, qemu-pr-helper
might open not only /dev/mapper/control but also individual
targets of the multipath device. We are already querying for them
in CGroups, but now we have to create them in the namespace too.
This was brought up in [1].

1: https://bugzilla.redhat.com/show_bug.cgi?id=1711045#c61Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NLin Ma <LMa@suse.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

The event loop thread will be responsible for handling
any per-domain I/O operations, most notably the QEMU
monitor and agent sockets.

We start this event loop when launching QEMU, but stopping
the event loop is a little more complicated. The obvious
idea is to stop it in qemuProcessStop(), but if we do that
we risk loosing the final events from the QEMU monitor, as
they might not have been read by the event thread at the
time we tell the thread to stop.

The solution is to delay shutdown of the event thread until
we have seen EOF from the QEMU monitor, and thus we know
there are no further events to process.

Note that this assumes that we don't have events to process
from the QEMU agent.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When preparing images for block jobs we modify their seclabels so
that QEMU can open them. However, as mentioned in the previous
commit, secdrivers base some it their decisions whether the image
they are working on is top of of the backing chain. Fortunately,
in places where we call secdrivers we know this and the
information can be passed to secdrivers.

The problem is the following: after the first blockcommit from
the base to one of the parents the XATTRs on the base image are
not cleared and therefore the second attempt to do another
blockcommit fails. This is caused by blockcommit code calling
qemuSecuritySetImageLabel() over the base image, possibly
multiple times (to ensure RW/RO access). A naive fix would be to
call the restore function. But this is not possible, because that
would deny QEMU the access to the base image.  Fortunately, we
can use the fact that seclabels are remembered only for the top
of the backing chain and not for the rest of the backing chain.
And thanks to the previous commit we can tell secdrivers which
images are top of the backing chain.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1803551Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Start virtiofsd for each <filesystem> device using it.

Pre-create the socket for communication with QEMU and pass it
to virtiofsd.

Note that virtiofsd needs to run as root.

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

Introduced by QEMU commit a43efa34c7d7b628cbf1ec0fe60043e5c91043ea
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Tested-by: NAndrea Bolognani <abologna@redhat.com>

Reject unsupported configurations.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Tested-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMasayoshi Mizuma <m.mizuma@jp.fujitsu.com>

Introduce a new 'virtiofs' driver type for filesystem.

<filesystem type='mount' accessmode='passthrough'>
  <driver type='virtiofs'/>
  <source dir='/path'/>
  <target dir='mount_tag'>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</filesystem>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Tested-by: NAndrea Bolognani <abologna@redhat.com>

Whenever there is a guest CPU configured in domain XML, we will call
some CPU driver APIs to validate the CPU definition and check its
compatibility with the hypervisor. Thus domains with guest CPU
specification can only be started if the guest architecture is supported
by the CPU driver. But we would add a default CPU to any domain as long
as QEMU reports it causing failures to start any domain on affected
architectures.

https://bugzilla.redhat.com/show_bug.cgi?id=1805755Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

While our code can detect ISO as a separate format, qemu does not use it
as such and just passes it through as raw. Add conversion for detected
parts of the backing chain so that the validation code does not reject
it right away.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Include virutil.h in all files that use it,
instead of relying on it being pulled in somehow.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>