The driver arg to virPCIDeviceDetach is no longer used (the name of the stub driver is now set in the virPCIDevice object, and virPCIDeviceDetach retrieves it from there). Remove it.

Commit 861d4056 added code (my personal change to "clean up" the
submitter's code, *not* the fault of the submitter) that dereferenced
virtVlan without first checking for NULL. This patch fixes that and,
as part of the fix, cleans up some unnecessary obtuseness.

As my punishment for the break in 7f15ebc7 (fixed in 752596b5) I'm
introducing this test to make sure it won't happen again. Currently,
only test for <graphics/> is supported.

Since we already have the v1.1.0-rc1 tag in git.

Free the old XML strings before overwriting them if the user
has chosen to reedit the file or force the redefinition.

Found by Alex Jia trying to reproduce another bug:
https://bugzilla.redhat.com/show_bug.cgi?id=977430#c3

virNetDevBridgeSetSTPDelay accepts delay in milliseconds,
but BSD implementation was expecting seconds. Therefore,
it was working correctly only with delay == 0.

This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.
Signed-off-by: NLaine Stump <laine@redhat.com>

I just learned that VFIO resets PCI devices when they are assigned to
guests / returned to the host, so it is redundant for libvirt to reset
the devices. This patch inhibits calling virPCIDeviceReset to devices
that will be/were assigned using VFIO.

The parameter specifies connection parameters to use for migrating
client's connection to domain's graphical console.

The patch implements wrappers for virDomainMigrate3 and
virDomainMigrateToURI3.

This patch introduces two new APIs virDomainMigrate3 and
virDomainMigrateToURI3 that may be used in place of their older
variants. These new APIs take optional migration parameters (such as
bandwidth, domain XML, ...) in an array of virTypedParameters, which
makes adding new parameters easier as there's no need to introduce new
APIs whenever a new migration parameter needs to be added. Both APIs are
backward compatible and will automatically use older migration calls in
case the new calls are not supported as long as the typed parameters
array does not contain any parameter which was not supported by the
older calls.

This patch implements extensible variants of all internal migration APIs
used for v3 migration.

To be used by new migration APIs with extensible set of parameters.

All APIs that take typed parameters are only using params address in
their entry point debug messages. With the new VIR_TYPED_PARAMS_DEBUG
macro, all functions can easily log all individual typed parameters
passed to them.

This API is useful for checking whether only a specific subset of
supported typed parameters were passed.

When unsupported parameter is passed to virTypedParamsValidate,
VIR_ERR_ARGUMENT_UNSUPPORTED should be returned rather than
VIR_ERR_INVALID_ARG, which is more appropriate for supported parameters
used incorrectly.

virPCIDeviceDetach would previously sometimes consume the input device
object (to put it on the inactive list) and sometimes not. Avoiding
memory leaks required checking beforehand to see if the device was
already on the list, and freeing the device object in the caller only
if there wasn't already an identical object on the inactive list.

This patch makes it consistent - virPCIDeviceDetach will *never*
consume the input virPCIDevice object; if it needs to put one on the
inactive list, it will create a copy and put *that* on the list. This
way the caller knows that it is always their responsibility to free
the device object they created.

virPCIDeviceReattach was making the assumption that the dev object
given to it was one and the same with the dev object on the
inactiveDevs list. If that had been the case, it would not need to
free the dev object it removed from the inactive list, because the
caller of virPCIDeviceReattach always frees the dev object that it
passes in. Since the dev object passed in is *never* the same object
that's on the list (it is a different object with the same name and
attributes, created just for the purpose of searching for the actual
object), simply doing a "ListSteal" to remove the object from the list
results in one leaked object; we need to actually free the object
after removing it from the list.

* virPCIDeviceFindByIDs - find a device on a list w/o creating an object
    This makes searching for an existing device on a list lighter weight.

* virPCIDeviceCopy - make a copy of an existing virPCIDevice object.

* virPCIDeviceGetDriverPathAndName - construct new strings containing
    1) the name of the driver bound to this device.
    2) the full path to the sysfs config for that driver.
    (This code was lifted from virPCIDeviceUnbindFromStub, and replaced
    there with a call to this new function).

Previously stubDriver was always set from a string literal, so it was
okay to use a const char * that wasn't freed when the virPCIDevice was
freed. This will not be the case in the near future, so it is now a
char* that is allocated in virPCIDeviceSetStubDriver() and freed
during virPCIDeviceFree().

add it to the syntax-check list and fix the one offending caller.

libxl supports the LIBXL_DISK_BACKEND_QDISK disk backend, where qemu
is used to provide the disk backend.  This patch simply maps the
existing <driver name='qemu'/> to LIBXL_DISK_BACKEND_QDISK.

Specifying an unsupported disk format with the tap driver resulted in
a less than helpful error message

error: Failed to start domain test-hvm
error: internal error libxenlight does not support disk driver qed

Change the message to state that the qed format is not supported by
the tap driver, e.g.

error: Failed to start domain test-hvm
error: internal error libxenlight does not support disk format qed
with disk driver tap

While at it, check for unsupported formats in the other driver
backends.

Add a script which parses the driver API code and validates
that every API registered in a virNNNDriverPtr table contains
an ACL check matching the API name.

NB this currently whitelists a few xen driver functions
which are temporarily lacking in access control checks.
The xen driver is considered insecure until these are
fixed.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>