Move the check out of virQEMUCapsInitQMPMonitor similarly to other
functions.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Some caps are cleared according to some more advanced logic after
detection. Split all that logic out into virQEMUCapsInitProcessCaps.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

virQEMUCapsInitQMPMonitor is massive now since it collects calls to the
various probing functions and also version based capabilities. Split
out the version based caps into a separate function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Convert the other string comparisons to use the macro.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Add hppa, nios2, or1k, riscv32 and riscv64 to the profile.

Fixes: https://bugs.debian.org/914940Signed-off-by: Nintrigeri <intrigeri@boum.org>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Check that the attribute is the same in qemuDomainDiskChangeSupported
in case somebody tries to change it using the UpdateDevice API.

https://bugzilla.redhat.com/show_bug.cgi?id=1601677Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

A macro for comparing string fields of the disk.

https://bugzilla.redhat.com/show_bug.cgi?id=1601677Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

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

This reverts commit 047cfb05
Using numeric comparison on strings means we reject every update
that does include the group name, even if it's unchanged.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Even though Coverity can prove that 'last' is always set if the prior
loop executed, gcc 8.0.1 cannot:

  CC       conf/libvirt_conf_la-virdomainmomentobjlist.lo
../../src/conf/virdomainmomentobjlist.c: In function 'virDomainMomentMoveChildren':
../../src/conf/virdomainmomentobjlist.c:178:19: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         last->sibling = to->first_child;
         ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~

Rewrite the loop to a form that should be easier for static analysis
to work with.

Fixes: ced0898fReported-by: NBjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

commit edaf1356 modified the stats retrieval for OVS interfaces to
not fail when one of the fields was unrecognized by the ovs-vsctl
command, but ovs-vsctl was still returning an error, and libvirt was
cluttering the logs with these inconsequential error messages.

This patch modifies the GET_STAT macro to add "--if-exists" to the
ovs-vsctl command, which causes it to return an empty string (and exit
with success) if the requested statistic isn't in its database, thus
eliminating the ugly error messages from the log.

Resolves: https://bugzilla.redhat.com/1683175Signed-off-by: NLaine Stump <laine@laine.org>

The warning is reported at a code path which already reports a proper
error so it's pointless to add yet another line into logs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Avoid the extra parameter passing in the disk 'dst' parameter to be
reported instead of the device alias. Using 'dst' instead of alias does
not add much value.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

qemuDomainRemoveDiskDevice calls qemuDomainReleaseDeviceAddress which
already calls virDomainUSBAddressRelease so we don't need to call it
again.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

There is one specific caller (testInfoSetArgs() in
qemuxml2argvtest.c) which expect the va_list argument to change
after returning from the virQEMUCapsSetVAList() function.
However, since we are passing plain va_list this is not
guaranteed. The man page of stdarg(3) says:

  If ap is passed to a function that uses va_arg(ap,type), then
  the value of ap is undefined after the return of that function.

(ap is a variable of type va_list)

I've seen this in action in fact: on i686 the qemuxml2argvtest
fails on the second test case because testInfoSetArgs() sees
ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the
capabilities (in this case there's just one
QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not
reflected in the caller, in the next iteration testInfoSetArgs()
sees the QEMU capability and not ARG_END.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 6b90a847.

It turns out gcc -O2 is not happy with it, complaining:

/home/pipo/libvirt/src/qemu/qemu_driver.c: In function 'qemuDomainSnapshotCreateXML':
/home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference]
     bool memory = snapdef->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL;
                   ~~~~~~~^~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference]
In file included from /home/pipo/libvirt/src/util/virbuffer.h:27,
                 from /home/pipo/libvirt/src/conf/capabilities.h:27,
                 from /home/pipo/libvirt/src/conf/domain_conf.h:32,
                 from /home/pipo/libvirt/src/qemu/qemu_agent.h:26,
                 from /home/pipo/libvirt/src/qemu/qemu_driver.c:40:
/home/pipo/libvirt/src/util/viralloc.h:125:34: error: potential null pointer dereference [-Werror=null-dereference]
 # define VIR_ALLOC_N(ptr, count) virAllocN(&(ptr), sizeof(*(ptr)), (count), true, \
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                            VIR_FROM_THIS, __FILE__, __FUNCTION__, __LINE__)
                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15103:9: note: in expansion of macro 'VIR_ALLOC_N'
     if (VIR_ALLOC_N(ret, snapdef->ndisks) < 0)
         ^~~~~~~~~~~
/home/pipo/libvirt/src/qemu/qemu_driver.c:15798:45: error: null pointer dereference [-Werror=null-dereference]
             virDomainSnapshotObjGetDef(snap)->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL) {
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~

As the patch simplified one or two callers at the risk of making
many other callers now candidates to trigger aggressive compiler
warnings, it isn't worth it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use the common base class virDomainMoment for iterator callbacks
related to snapshots from the qemu code, so that when checkpoint
operations are introduced, they can share the same callbacks.

Simplify the code for qemuDomainSnapshotCurrent by better utilizing
virDomainMoment helpers.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Doing so can simplify some callers.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The qemu driver already had a full-blown virDomainMomentObjPtr to
check against, and the test driver ought to have one since we get
better error checking that the user passed in a valid object. Removes
the need for a helper function added in commit commit 4819f54b.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The VIR_MIGRATE_PARALLEL flag is implemented using QEMU's multifd
migration capability and the corresponding multifd-channels migration
parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Prepare for introducing a bunch of new public APIs related to
backup checkpoints by first introducing a new internal type
and errors associated with that type.  Checkpoints are modeled
heavily after virDomainSnapshotPtr (both represent a point in
time of the guest), although a snapshot exists with the intent
of rolling back to that state, while a checkpoint exists to
make it possible to create an incremental backup at a later
time.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since I was copying this text to form checkpoint XML and API
documentation, I might as well make improvements along the way. Most
of these changes are based on reviews of the checkpoint docs.

Among other things: grammar tweaks, point to a single source of
documentation rather than repeating verbosity, reword things for
easier legibility.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 86c0ed6f, and
subsequent refactorings of the function into new files.  There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also tried using it for streamlining how
the qemu driver stores snapshot state across libvirtd restarts
internally, but in the end, the risks of a new internal format
outweighed the benefits of one file per snapshot.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 1b57269c, and
subsequent refactorings of the function into new files.  There are no
callers of this function - I had originally proposed it for
implementing a new bulk snapshot API, but that proved to be too
invasive given RPC limits. I also tried using it for streamlining how
the qemu driver stores snapshot state across libvirtd restarts
internally, but in the end, the risks of a new internal format
outweighed the benefits of one file per snapshot.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

For [some unknown reason, possibly/probably pure chance], Net devices
have been taken offline and their bandwidth tc rules cleared as the
very first operation when detaching the device. This is contrary to
every other type of device, where all hostside teardown is delayed
until we receive the DEVICE_DELETED event back from qemu, indicating
that the guest has finished with the device.

This patch delays these two operations until receipt of
DEVICE_DELETED, which removes an ugly wart from
qemuDomainDetachDeviceLive(), and also seems to be a more correct
sequence of events.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

The VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event is sent after qemu has
responded to a device_del command with a DEVICE_DELETED event. Before
queuing the event, *some* of the final teardown of the device's
trappings in libvirt is done, but not *all* of it. As a result, an
application may receive and process the DEVICE_REMOVED event before
libvirt has really finished with it.

Usually this doesn't cause a problem, but it can - in the case of the
bug report referenced below, vdsm is assigning a PCI device to a guest
with managed='no', using livirt's virNodeDeviceDetachFlags() and
virNodeDeviceReAttach() APIs. Immediately after receiving a
DEVICE_REMOVED event from libvirt signalling that the device had been
successfully unplugged, vdsm would cal virNodeDeviceReAttach() to
unbind the device from vfio-pci and rebind it to the host driverm but
because the event was received before libvirt had completely finished
processing the removal, that device was still on the "activeDevs"
list, and so virNodeDeviceReAttach() failed.

Experimentation with additional debug logs proved that libvirt would
always end up dispatching the DEVICE_REMOVED event before it had
removed the device from activeDevs (with a *much* greater difference
with managed='yes', since in that case the re-binding of the device
occurred after queuing the device).

Although the case of hostdev devices is the most extreme (since there
is so much involved in tearing down the device), *all* device types
suffer from the same problem - the DEVICE_REMOVED event is queued very
early in the qemuDomainRemove*Device() function for all of them,
resulting in a possibility of any application receiving the event
before libvirt has really finished with the device.

The solution is to save the device's alias (which is the only piece of
info from the device object that is needed for the event) at the
beginning of processing the device removal, and then queue the event
as a final act before returning. Since all of the
qemuDomainRemove*Device() functions (except
qemuDomainRemoveChrDevice()) are now called exclusively from
qemuDomainRemoveDevice() (which selects which of the subordinates to
call in a switch statement based on the type of device), the shortest
route to a solution is to doing the saving of alias, and later
queueing of the event, in the higher level qemuDomainRemoveDevice(),
and just completely remove the event-related code from all the
subordinate functions.

The single exception to this, as mentioned before, is
qemuDomainRemoveChrDevice(), which is still called from somewhere
other than qemuDomainRemoveDevice() (and has a separate arg used to
trigger different behavior when the chr device has targetType ==
GUESTFWD), so it must keep its original behavior intact, and must be
treated differently by qemuDomainRemoveDevice() (similar to the way
that qemuDomainDetachDeviceLive() treats chr and lease devices
differently from all the others).

Resolves: https://bugzilla.redhat.com/1658198Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

Now that all the qemuDomainDetachPrep*() functions look nearly
identical at the end, we can put one copy of that identical code in
qemuDomainDetachDeviceLive() at the point after the individual prep
functions have been called, and remove the duplicated code from all
the prep functions. The code to locate the target "detach" device
based on the "match" device remains, as do all device-type-specific
validations.

Unfortunately there are a few things going on at once in this patch,
which makes it a bit more difficult to follow than the others; it was
just impossible to do the changes in stages and still have a
buildable/testable tree at each step.

The other changes of note:

* The individual prep functions no longer need their driver or async
  args, so those are removed, as are the local "ret" variables, since
  in all cases the functions just directly return -1 or 0.

* Some of the prep functions were checking for a valid alias and/or
  for attempts to detach a multifunction PCI device, but not all. In
  fact, both checks are valid (or at least harmless) for *all* device
  types, so they are removed from the prep functions, and done a
  single time in the common function.

  (any attempts to *create* an alias when there isn't one has been
  removed, since that is doomed to failure anyway; the only way the
  device wouldn't have an alias is if 1) the domain was created by
  calling virsh qemu-attach to attach an existing qemu process to
  libvirt, and 2) the qemu command that started said process used "old
  style" arguments for creating devices that didn't have any device
  ids. Even if we constructed a device id for one of these devices,
  qemu wouldn't recognize it in the device_del command anyway, so we
  may as well fail earlier with "device missing alias" rather than
  failing later with "couldn't delete device net0".)

* Only one type of device has shutdown code that must not be called
  until after *all* validation of the device is done (including
  checking for multifunction PCI and valid alias, which is done in the
  toplevel common code). For this reason, the Net function has been
  split in two, with the 2nd half (qemuDomainDetachShutdownNet())
  called from the common function, right before sending the delete
  command to qemu.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

Although all hotpluggable devices other than lease, controller,
watchdof, and vsock can be audited, and *are* audited when an unplug
is successful, only disk, net, and hostdev were actually being audited
on failure.

This patch corrects that omission.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

This function can be called with a virDomainDevicePtr and whether or
not the removal was successful, and it will call the appropriate
virDomainAudit*() function with the appropriate args for whatever type
of device it's given (or do nothing, if that's appropriate). This
permits generalizing some code that currently has a separate copy for
each type of device.

NB: Although the function initially will be called only with
success=false, that has been made an argument so that in the future
(when the qemuDomainRemove*Device() functions have had their common
functionality consolidated into qemuDomainRemoveDevice()), this new
common code can call qemuDomainRemoveAuditDevice() for all types.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

qemuDomainDetachDeviceChr and qemuDomainDetachDeviceLease are more
consistent with each other.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

Most of these functions will soon contain only some setup for
detaching the device, not the detach code proper (since that code is
identical for these devices). Their device specific functions are all
being renamed to qemuDomainDetachPrep*(), where * is the
name of that device's data member in the virDomainDeviceDef
object.

Since there will be other code in qemuDomainDetachDeviceLive() after
the calls to qemuDomainDetachPrep*() that could still fail, we no
longer directly set "ret" with the return code from
qemuDomainDetachPrep*() functions, but simply return -1 on
failure, and wait until the end of qemuDomainDetachDeviceLive() to set
ret = 0.

Along with the rename, qemuDomainDetachPrep*() functions are also
given similar arglists, including an arg called "match" that points to
the proto-object of the device we want to delete, and another arg
"detach" that is used to return a pointer to the actual object that
will be (for now *has been*) detached. To make sure these new args
aren't confused with existing local pointers that sometimes had the
same name (detach), the local pointer to the device is now named after
the device type ("controller", "disk", etc). These point to the same
place as (*detach)->data.blah, it's just easier on the eyes to have,
e.g., "disk->dst" rather than "(*detach)->data.disk-dst".
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

The Chr and Lease devices have detach code that is too different from
the other device types to handle with common functionality (which will
soon be added at the end of qemuDomainDetachDeviceLive(). In order to
make this difference obvious, move the cases for those two device
types to the top of the switch statement in
qemuDomainDetachDeviceLive(), have the cases return immediately so the
future common code at the end of the function will be skipped, and
also include some hopefully helpful comments to remind future
maintainers why these two device types are treated differently.

Any attempt to detach an unsupported device type should also skip the
future common code at the end of the function, so the case for
unsupported types is similarly changed from a simple break to a return
-1.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

I'm about to add a second virDomainDeviceDef to this function that
will point to the actual device in the domain object. while this is
just a partially filled-in example of what to look for. Naming it
match will make the code easier to follow.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

These are no longer called from qemu_driver.c, since the function that
called them (qemuDomainDetachDeviceLive()) has been moved to
qemu_hotplug.c, and they are no longer called from testqemuhotplug.c
because it now just called qemuDomainDetachDeviceLive() instead of all
the subordinate functions.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

qemuDomainDetachDeviceLive() is called from two places in
qemu_driver.c, and qemuDomainUpdateDeviceList() is called from the
end of qemuDomainDetachDeviceLive(), which is now in qemu_hotplug.c

This patch replaces the single call to qemuDomainUpdateDeviceList()
with two calls to it immediately after return from
qemuDomainDetachDeviceLive(). This is only done if the return from
that function is exactly 0, in order to exactly preserve previous
behavior.

Removing that one call from qemuDomainDetachDeviceList() will permit
us to call it from the test driver hotplug test, replacing the
separate calls to qemuDomainDetachDeviceDiskLive(),
qemuDomainDetachChrDevice(), qemuDomainDetachShmemDevice() and
qemuDomainDetachWatchdog(). We want to do this so that part of the
common functionality of those three functions (and the rest of the
device-specific Detach functions) can be pulled up into
qemuDomainDetachDeviceLive() without breaking the test. (This is done
in the next patch).

NB: Almost certainly this is "not the best place" to call
qemuDomainUpdateDeviceList() (actually, it is provably the *wrong*
place), since it's purpose is to retrieve an "up to date" list of
aliases for all devices from qemu, and if the guest OS hasn't yet
processed the detach request, the now-being-removed device may still
be on that list. It would arguably be better to instead call
qemuDomainUpdateDevicesList() later during the response to the
DEVICE_DELETED event for the device. But removing the call from the
current point in the detach could have some unforeseen ill effect due
to changed timing, so the change to move it into
qemuDomainRemove*Device() will be done in a separate patch (in order
to make it easily revertible in case it causes a regression).
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

qemuDomainDetachDeviceControllerLive() just checks if the controller
type is SCSI, and then either returns failure, or calls
qemuDomainDetachControllerDevice().

Instead, lets just check for type != SCSI at the top of the latter
function, and call it directly.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

This function is going to take on some of the functionality of its
subordinate functions, which all live in qemu_hotplug.c.

qemuDomainDetachDeviceControllerLive() is only called from
qemuDomainDetachDeviceLive() (and will soon be merged into
qemuDomainDetachControllerDevice(), which is in qemu_hotplug.c), so
it is also moved.
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

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

They were added in qemu commit 7572150c189c6553c2448334116ab717680de66d
released in v0.14.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Rather than hard-coding the snapshot filter bit values into the
generic code, add another layer of indirection: callers must map which
of their public filter bits correspond to supported moment bits, then
pass two separate flags (the ones translated for moment code to
operate on, and the remaining ones for the filter callback to operate
on).
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The Attach and Detach Lease functions were together in the middle of
the Detach functions. Put them at the end of their respective
sections, since they behave differently from the other attach/detach
functions (DetachLease doesn't use qemuDomainDeleteDevice(), and is
always synchronous).
Signed-off-by: NLaine Stump <laine@laine.org>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>