This capability enables comparison of CPU models via QMP.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Message-Id: <1568924706-2311-13-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Interfaces with QEMU to compare CPU models. The command takes two CPU
models, A and B, that are given a model name and an optional list of
CPU features. Through the query-cpu-model-comparison command issued
via QMP, a result is produced that contains the comparison evaluation
string (identical, superset, subset, incompatible).

The list of properties (aka CPU features) that is returned from the QMP
response is ignored.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-12-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Perform a full CPU model expansion on the result of the baselined
model name when the features flag is present.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-11-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This command is hooked into the virsh hypervisor-cpu-baseline command.
The CPU models provided in the XML sent to the command will be baselined
via the query-cpu-model-baseline QMP command. The resulting CPU model
will be reported.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-10-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This capability enables baselining of CPU models via QMP.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Message-Id: <1568924706-2311-9-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Interfaces with QEMU to baseline CPU models. The command takes two
CPU models, A and B, that are given a model name and an optional list
of CPU features. Through the query-cpu-model-baseline command issued
via QMP, a result is produced that contains a new baselined CPU model
that is guaranteed to run on both A and B.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielh413@gmail.com>
Message-Id: <1568924706-2311-8-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Modify the error messages in qemuMonitorJSONParseCPUModelData to print
the command name provided to the function.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-7-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Some older s390 CPU models (e.g. z900) will not report props as a
response from query-cpu-model-expansion. As such, we should make the
props field optional when parsing the return data from the QMP response.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

query-cpu-model-baseline/comparison will accept a list of features
as part of the command. Since CPUs may be defined with CPU feature
policies, let's parse it to the appropriate boolean that the QMP
command expects.

A feature that is set to required, force, or if it is a hypervisor
CPU feature (-1), then set the property value to true. Otherwise
(optional, disabled) set the value to false.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-5-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

When expanding a CPU model via query-cpu-model-expansion, any features
that were a part of the original model are discarded. For exmaple,
when expanding modelA with features f1, f2, a full expansion may reveal
feature f3, but the expanded model will not include f1 or f2.

Let's pass a virCPUDefPtr to the expansion function in preparation for
taking features into consideration.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

With refactoring most of the expansion function, let's take care of
some additional cleanups.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-3-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Refactor some code in qemuMonitorJSONGetCPUModelExpansion to be later
used for the comparison and baseline functions.
Signed-off-by: NCollin Walling <walling@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <1568924706-2311-2-git-send-email-walling@linux.ibm.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Parseability of disk name is now checked in qemuDomainDeviceDefValidateDisk().
Signed-off-by: NPavel Mores <pmores@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The way in which the qemu driver generates aliases for disks involves
ignoring the partition number part of a target dev name.  This means that
all partitions of a block device and the device itself all end up with the
same alias.  If multiple such disks are specified in XML, the resulting
name clash makes qemu invocation fail.

Since attaching partitions to qemu VMs doesn't seem to make much sense
anyway, disallow partitions in target specifications altogether.

https://bugzilla.redhat.com/show_bug.cgi?id=1346265Signed-off-by: NPavel Mores <pmores@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In the domain capabilities XML there are FW image paths printed.
There are two sources for the image paths (in order of
preference):

  1) firmware descriptor files - as returned by
  qemuFirmwareGetSupported()

  2) a compile time list of FW:NRAM pairs which can be overridden
  in qemu.conf

If either of those contains a duplicate FW image path (which is
a valid use case) it is printed twice in the capabilities XML.
While it's technically not a bug, it doesn't look good.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Similarly to the snapshot code there's no reason to modify current
checkpoint until we are done creating the new one.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since commit f1056279 we store whether a snapshot is current globally
rather than locally in the snapshot object.

This means that we don't have to unset the current snapshot prior to
taking/reverting the snapshot and we can do it only when everything is
done successfully.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Ensure that the FD we're passing to QEMU is actually open, so we get a
sane error message upfront instead of telling QEMU to use a closed FD.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The video private data was not initializing the vhostuser FD
causing us to attempt to close FD 0 many times over.

Fixes

  commit ca60ecfa
  Author: Marc-André Lureau <marcandre.lureau@redhat.com>
  Date:   Mon Sep 23 14:44:36 2019 +0400

      qemu: add qemuDomainVideoPrivate

Since the test suite does not invoke qemuExtDevicesStart(), no
vhost_user_fd will be present when generating test XML. To deal
with this we can must a fake FD number. While the current XML
is using FD == 0, we pick a very interesting number that's unlikely
to be a real FD, so that we're more likely to see any mistakes
closing the invalid FD.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Now it's not used outside of qemu_monitor_json.c.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Use the generators provided by the monitor code instead.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Use the new generator residing in the monitor code rather than directly
using qemuMonitorJSONTransactionAdd.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Unify with other code that generates parameters for the 'transaction'
command.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Rather than generating the transaction contents in random places add a
unified set of APIs to generate the contents for a 'transaction' for the
dirty bitmap APIs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The QEMU_CAPS_INCREMENTAL_BACKUP will be enabled once all bits of the
incremental backup feature work as expected which means also properly
interacting with blockjobs and snapshots.

Thus we can allow blockjobs and snapshots if QEMU_CAPS_INCREMENTAL_BACKUP
is present even when checkpoints exist.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Rather than having to fix 5 places once we support the combination, add
a function called by all the blockjob/snapshot APIs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Checkpoints by themselves are not very useful for anything else than
testing the few bitmap interactions that are currently implemented.

It's very unlikely that anybody used this feature and thus we can
disable it until we have a more complete implementation ready.

Additionally the code for deleting checkpoints has many broken failure
scenarios which should be fixed first. This will require support of
deleting a bitmap in a qemu 'transaction' which was not released yet.

Curious users obviously can use the qemu namespace in the XML to enable
this for experiments:

  <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
    ...
    <qemu:capabilities>
      <qemu:add capability='incremental-backup'/>
    </qemu:capabilities>
  </domain>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add a new all-covering capability which will be used to interlock
incremental backup support until all bits are ready.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add a 'cleanup' label and use jumps as we do in other places.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Once somebody is motivated enough to add the support for the quiesce
flag or offline checkpoint deletion they are welcome to do so but we
don't need to have a reminder.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Use VIR_AUTO* helpers and get rid of the 'cleanup' label.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

There's nothing that uses it directly now. Also not allowing direct use
will promote our layering.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Finish the refactor by moving and renaming functions from qemu_domain.c
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Move all extensive functions to a new file so that we don't just pile
everything in the common files. This obviously isn't possible with
straight code movement as we still need stubs in qemu_driver.c

Additionally some functions e.g. for looking up a checkpoint by name
were so short that moving the impl didn't make sense.

Note that in the move the new file also doesn't use
virQEMUMomentReparent but rather an stripped down copy. As I plan to
split out snapshot code into a separate file the unification doesn't
make sense any more.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The interlocking with snapshots is executed prior to the ACL check so if
a VM has snapshots invoking the checkpoint API may leak it's existance.

Introduced with the qemuDomainCheckpointCreateXML API implementation in
commit 5f4e0796.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The code that gets the job to refresh disk sizes was not merged yet so
remove this artifact.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

'vm' is passed in which contains the definition which contains the UUID
so we don't need another parameter for this.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'vm' is passed in which contains the definition which contains the UUID
so we don't need another parameter for this.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move it to qemu_domain.c and rename it to qemuDomainObjFromDomain. This
will allow reusing it after splitting out checkpoint code from
qemu_driver.c.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

As it turns out, on my 32bit ARM machine size_t is not the same
size as ULL. However, @length argument for both functions is type
of size_t but it's treated as ULL - for instance when passed to
qemuMonitorJSONMakeCommand(). The problem is that because of
"U:size" the virJSONValueObjectAddVArgs() expects an ULL argument
but on the stack there are size_t and char * arguments (which
coincidentally add up to size of ULL). So the created command has
only two arguments "val" and incorrect "size" and no "path" which
is required.

I've tried to find other occurrences of this pattern but at the
rest of places where size_t is used it tracks size of an array so
that's safe.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>