cputest: Add cpuidLeaf helper to cpu-cpuid.py

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Add cpuidIsSet helper to cpu-cpuid.py

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Rename cpu-convert.py script as cpu-cpuid.py

The new script is going to be more general and the original
functionality can be requested by "cpu-cpuid.py convert".

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cputest: Move instantiation of JSONDecoder in cpu-convert.py

Let's make the object local to the parseFeatureWords function which uses
it.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Do not pass virConnectBaselineCPUFlags to cpuBaseline

The public API flags are handled by the cpuBaselineXML wrapper. The
internal cpuBaseline API only needs to know whether it is supposed to
drop non-migratable features.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Move feature expansion out of cpuBaseline

cpuBaseline is responsible for computing a baseline CPU while feature
expansion is done by virCPUExpandFeatures. The cpuBaselineXML wrapper
(used by hypervisor drivers to implement virConnectBaselineCPU API)
calls cpuBaseline followed by virCPUExpandFeatures if requested by
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag.

The features in the three changed test files had to be sorted using
"sort -k 3" because virCPUExpandFeatures returns a sorted list of
features.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Drop unused flags from cpuArchDecode

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu: Introduce virCPUExpandFeatures

Having to use cpuBaseline with VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES
flag to expand CPU features is strange. Not to mention that cpuBaseline
can only expand host CPU definitions (i.e., it completely ignores
feature policies). The new virCPUExpandFeatures API is designed to work
with both host and guest CPU definitions.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

cpu_conf: Introduce virCPUDefFreeFeatures

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

docs: make interface start mode element optional

This brings the libvirt version of this RNG file in line with the same
file in netcf (as soon as the corresponding patch there is ACKed and
pushed).

There's no reason to require it when defining an interface (the config
option it corresponds to is optional), and it isn't even output in the
status of an interface.

Resolves: https://bugzilla.redhat.com/1414404

conf: validate that PCI controller index is < 256

This is the maximum for many reasons, for starters because index ==
bus number, and a controller's bus number is 8 bits.

This incidentally resolves: https://bugzilla.redhat.com/1329090

util: rename virHostdevNetConfigRestore() to virHostdevRestoreNetConfig()

util: log all setting of MAC addresses and vlan tags

Having this information available will make it easier to determine the
culprit when MAC or vlan tag appear to not be set, eg.:

  https://bugzilla.redhat.com/1364073

(This patch doesn't fix that bug, just makes it easier to diagnose)

util: try *really* hard to set the MAC address of an SRIOV VF

If an SRIOV VF has previously been used for VFIO device assignment,
the "admin MAC" that is stored in the PF driver's table of VF info
will have been set to the MAC address that the virtual machine wanted
the device to have. Setting the admin MAC for a VF also sets a flag in
the PF that is loosely called the "administratively set" flag. Once
that flag is set, it is no longer possible for the net driver of the
VF (either on the host or in a virtual machine) to directly set the
VF's MAC again; this flag isn't reset until the *PF* driver is
restarted, and that requires taking *all* VFs offline, so it's not
really feasible to do.

If the same SRIOV VF is later used for macvtap passthrough mode, the
VF's MAC address must be set, but normally we don't unbind the VF from
its host net driver (since we actually need the host net driver in
this case). Since setting the VF MAC directly will fail, in the past
"we" ("I") had tried to fix the problem by simply setting the admin MAC
(via the PF) instead. This *appeared* to work (and might have at one
time, due to promiscuous mode being turned on somewhere or something),
but it currently creates a non-working interface because only the
value for admin MAC is set to the desired value, *not* the actual MAC
that the VF is using.

Earlier patches in this series reverted that behavior, so that we once
again set the MAC of the VF itself for macvtap passthrough operation,
not the admin MAC. But that brings back the original bug - if the
interface has been used for VFIO device assignment, you can no longer
use it for macvtap passthrough.

This patch solves that problem by noticing when virNetDevSetMAC()
fails for a VF, and in that case it sets the desired MAC to the admin
MAC via the PF, then "bounces" the VF driver (by unbinding and the
immediately rebinding it to the VF). This causes the VF's MAC to be
reinitialized from the admin MAC, and everybody is happy (until the
*next* time someone wants to set the VF's MAC address, since the
"administratively set" bit is still turned on).

util: if setting admin MAC to 00:00:00:00:00:00 fails, try 02:00:00:00:00:00

Some PF drivers allow setting the admin MAC (that is the MAC address
that the VF will be initialized to the next time the VF's driver is
loaded) to 00:00:00:00:00:00, and some don't. Multiple drivers
initialize the admin MACs to all 0, but don't allow setting it to that
very same value. It has been an uphill battle convincing the driver
people that it's reasonable to expect The argument that's used is
that an all 0 device MAC address on a device is invalid; however, from
an outsider's point of view, when the admin MAC is set to 0 at the
time the VF driver is loaded, the VF's MAC is *not* set to 0, but to a
random non-0 value. But that's beside the point - even if I could
convince one or two SRIOV driver maintainers to permit setting the
admin MAC to 0, there are still several other drivers.

So rather than fighting that losing battle, this patch checks for a
failure to set the admin MAC due to an all 0 value, and retries it
with 02:00:00:00:00:00. That won't result in a random value being set
in the VF MAC at next VF driver init, but that's okay, because we
always want to set a specific value anyway. Rather, the "almost 0"
setting makes it easy to visually detect from the output of "ip link
show" which VFs are currently in use and which are free.

util: remove unused functions from virnetdev.c

The global functions virNetDevReplaceMacAddress(),
virNetDevReplaceNetConfig(), virNetDevRestoreMacAddress(), and
virNetDevRestoreNetConfig() are no longer used, as their functionality
has been replaced by virNetDev(Save|Read|Set)NetConfig().

The static functions virNetDevReplaceVfConfig() and
virNetDevRestoreVfConfig() were only used by the above-named global
functions that were removed.

util: after hostdev assignment, restore VF MAC address via setting admin MAC

It takes longer to explain this than to fix it...

In the past we weren't able to save the VF's own MAC address *at all*
when using it for hostdev assignment, because we had already unbound
the VF from the host net driver prior to saving its config. With the
previous patch, that problem has been solved, so we now have the VF's
MAC address saved and can move on to the *next* problem, which is twofold:

1) during teardown we restore the config before we've re-bound, so the
   VF doesn't have a net driver, and thus we can't set its MAC address
   directly.

2) even if we delay restoring the config until the VF is bound to a
   net driver, the request to set its MAC address would fail, since
   (during device setup) we had set the "admin MAC" for the VF via an
   RTM_SETLINK to the PF - once you've set the admin MAC for a VF, the
   VF driver (either on host or on guest) is not allowed to change the
   VF's MAC address "forever" (well, until you reload the PF driver,
   but that requires destroying and recreating every single VF, which
   isn't something you can require).

The solution is to keep the restoration of config at the same place,
but to set the *admin MAC* to the address you want the VF to have -
when the VF net driver is later initialized (as a part of re-binding
to the VF net driver) its MAC will be initialized to the current value
of the admin MAC.

util: save hostdev network device config before unbinding from host driver

In order to properly restore the original state of an SRIOV VF when
we're finished with it, we need to save the MAC address of the VF
itself (not just the admin MAC address for the VF that is stored in
the PF). But that can only be done when the VF is still bound to the
host's netdev driver, and we have always done the saving of device
config after the VF is already bound to vfio-pci. This patch prepares
us for adding a save of the VF's MAC by calling the function that
saves netconfig earlier in the device preparation, before we've
unbound it from the host netdev driver.

util: replace virHostdevNetConfigReplace with ...(Save|Set)NetConfig()

These two operations will need to be separated so that saving of the
original config is done before detaching the host net driver, and
setting the new config is done after attaching vfio-pci. This patch
splits the single function into two, but for now calls them together
(to make bisecting easier if there is a regression).

util: use new virNetDev*NetConfig() functions for hostdev setup/teardown

virHostdevNetConfigReplace() and virHostdevNetConfigRestore() are
modified to use the new virNetDev*NetConfig() functions.

Note that due to the VF's original MAC addresses being saved after it
has already been un-bound from the host net driver, the actual current
VF MAC address won't be saved (because it no longer exists) - only the
"admin MAC" will be saved. This reflects existing behavior that will
be fixed in an upcoming patch.

util: use new virNetDev*NetConfig() functions for macvtap setup/teardown

This patch modifies the macvtap passthrough setup to use
virNetDevSaveNetConfig()+virNetDevSetConfig() instead of
virNetDevReplaceNetConfig() or virNetDevReplaceMacAddress(), and the
teardown to use virNetDevReadNetConfig()+virNetDevSetConfig() instead
of virNetDevRestoreNetConfig() or virNetDevRestoreMacAddress().

Since the older functions only saved/restored the admin MAC and vlan
tag (which is incorrect) and the new functions save/restore the VF's
own MAC address and vlan tag (correct), this actually fixes a bug
(which was introduced by commit cb3fe38c7, which was itself supposed
to be a fix for https://bugzilla.redhat.com/1113474 ).

The downside to this patch is that it causes an *apparent* regression
in that bug (because there will once again be an error reported if the
interface had previously been used for VFIO device assignment), but in
reality, the code hasn't been working for *any* case before this
current patch (at least not with any recent kernel). Anyway, that
"regression" will be fixed with an upcoming patch that fixes it the
*right* way.

util: new functions virNetDev(Save|Read|Set)NetConfig()

These three functions are destined to replace
virNetDev(Replace|Restore)NetConfig() and
virNetDev(Replace|Restore)MacAddress(), which both do the save and set
together as a single step. We need to separate the save, read, and set
steps because there will be situations where we need to do something
else in between (in particular, we will need to rebind a VF's driver
after save but before set).

This patch creates the new functions, but doesn't call them - that
will come in a subsequent patch. Note that the new functions to
read/write the file that stores the original network config now uses
JSON rather than plaintext (it still recognizes the old format as well
though, so it won't get confused during an upgrade).

qemu: Log additional data from hyperv crash notifier

The hyperv panic notifier reports additional data in form of 5 registers
that are reported in the crash event from qemu. Log them into the VM log
file and report them as a warning so that admins can see the cause of
crash of their windows VMs.

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

qemu: monitor: Extract additional info from GUEST_PANICKED event

For certain kinds of panic notifiers (notably hyper-v) qemu is able to
report some data regarding the crash passed from the guest.

Make the data accessible to the callback in qemu so that it can be
processed further.

qemu: driver: Fix formatting in processGuestPanicEvent

qemu: driver: Remove useless forward declarations

news: Update our NEWS file about addition of the mdevs

Signed-off-by: Erik Skultety <eskultet@redhat.com>

docs: Document the new hostdev type 'mdev'

Signed-off-by: Erik Skultety <eskultet@redhat.com>

test: Add some test cases for our test suite regarding the mdevs

For now, these only cover the unmanaged, i.e. user pre-created devices.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

qemu: Format mdevs on qemu command line

Format the mediated devices on the qemu command line as
-device vfio-pci,sysfsdev='/path/to/device/in/syfs'.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

qemu: Bump the memory locking limit for mdevs as well

Since mdevs are just another type of VFIO devices, we should increase
the memory locking limit the same way we do for VFIO PCI devices.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

qemu: cgroup: Adjust cgroups' logic to allow mediated devices

As goes for all the other hostdev device types, grant the qemu process
access to /dev/vfio/<mediated_device_iommu_group>.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

hostdev: Maintain a driver list of active mediated devices

Keep track of the assigned mediated devices the same way we do it for
the rest of hostdevs. Methods like 'Prepare', 'Update', and 'ReAttach'
are introduced by this patch.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

qemu: Assign PCI addresses for mediated devices as well

So far, the official support is for x86_64 arch guests so unless a
different device API than vfio-pci is available let's only turn on
support for PCI address assignment. Once a different device API is
introduced, we can enable another address type easily.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

conf: Enable cold-plug of a mediated device

This merely introduces virDomainHostdevMatchSubsysMediatedDev method that
is supposed to check whether device being cold-plugged does not already
exist in the domain configuration.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

security: Enable labeling of vfio mediated devices

This patch updates all of our security driver to start labeling the
VFIO IOMMU devices under /dev/vfio/ as well.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

conf: Introduce new hostdev device type mdev

A mediated device will be identified by a UUID (with 'model' now being
a mandatory <hostdev> attribute to represent the mediated device API) of
the user pre-created mediated device. We also need to make sure that if
user explicitly provides a guest address for a mdev device, the address
type will be matching the device API supported on that specific mediated
device and error out with an incorrect XML message.

The resulting device XML:
<devices>
  <hostdev mode='subsystem' type='mdev' model='vfio-pci'>
    <source>
      <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'>
    </source>
  </hostdev>
</devices>

Signed-off-by: Erik Skultety <eskultet@redhat.com>

util: Introduce new module virmdev

Beside creation, disposal, getter, and setter methods the module exports
methods to work with lists of mediated devices.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

conf: Introduce virDomainHostdevDefPostParse

Just to make the code a bit cleaner, move hostdev specific post parse
code to its own function just in case it grows in the future.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

conf: hostdev: Introduce virDomainHostdevSubsysSCSIClear

Just a tiny wrapper over the SCSI def clearing logic to drop some
if-else branches from a switch, mainly because extending the switch in
the future would render the current code with branching less readable.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

conf: hostdev: Enforce enum-in-switch compile-time checks

Enforce virDomainHostdevSubsysType checking during compilation. Again,
one of a few spots in our code where we should enforce the typecast to
the enum type, thus not forgetting to update *all* switch occurrences
dealing with the give enum.

Signed-off-by: Erik Skultety <eskultet@redhat.com>

util: fix build on RHEL 6

We keep forgetting that older setups don't like 'index':

  CC     util/libvirt_util_la-virsysinfo.lo
cc1: warnings being treated as errors
util/virstoragefile.c: In function 'virStorageSourceFindByNodeName':
util/virstoragefile.c:3804: error: declaration of 'index' shadows a global declaration [-Wshadow]
/usr/include/string.h:489: error: shadowed declaration is here [-Wshadow]

Signed-off-by: Eric Blake <eblake@redhat.com>

tests: Enhance vircaps2xml test

Instead of generating all of the capabilities, let's test more of our
code by probing sysfs data.  This test needs quite some mocking for
now, but it paves the road for more future enhancements (hugepages
probing, for example).

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Add virnumamock

All mocked functions are related to numactl/virNuma and rely only on
virsysfs, so the paths they touch can be nicely controlled.  And
because it is so nicely self-contained NUMA mock, it is named
numamock (instead of naming it after the test that will use it first).

We need top level API mock because some APIs might call libnuma
directly, e.g. virNumaIsAvailable(), virNumaGetMaxNode().

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Add linux-caches sysfs entries for vircaps2xmltest

Bit more test data, this time with complete info copied, mainly with
cache information, so we can easily add tests for it.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Add sysfs node/cpu topology for the only vircaps2xml testcase

We'll stop generating the data on the fly, but rather test more of our
APIs.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Change virQEMUCapsInitPages to virCapabilitiesInitPages

This way more drivers can utilize the functionality without copying
the code.  And we can therefore test it in one place for all of them.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

util: Fix naming in util/virnodesuspend

That file has only two exported files and each one of them has
different naming.  virNode is what all the other files use, so let's
use it.  It wasn't used before because the clash with public API
naming, so let's fix that by shortening the name (there is no other
private variant of it anyway).

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Remove src/nodeinfo

There is no "node driver" as there was before, drivers have to do
their own ACL checking anyway, so they all specify their functions and
nodeinfo is basically just extending conf/capablities.  Hence moving
the code to src/conf/ is the right way to go.

Also that way we can de-duplicate some code that is in virsysfs and/or
virhostcpu that got duplicated during the virhostcpu.c split.  And
Some cleanup is done throughout the changes, like adding the vir*
prefix etc.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Move src/fdstream to src/util/virfdstream

There is no reason for it not to be in the utils, all global symbols
under that file already have prefix vir* and there is no reason for it
to be part of DRIVER_SOURCES because that is just a leftover from
older days (pre-driver modules era, I believe).

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

util: Adapt virhostcpu to the new virsysfs

While on that, drop support for kernels from RHEL-5 era (missing
cpu/present file).  Also add some useful functions and export them.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

util: Add virsysfs for handling sysfs files

By using this we are able to easily switch the sysfs path being
used (fake it).  This will not only help tests in the future but can
be also used from files where the code is duplicated currently.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Add cpu/{online,present} files for old tests

The functionality these tests partially relied on (scanning the cpu
directory for cpu[0-9]+ subdirectories) is going to be removed, so we
need additional files that are present on all non-medieval systems.
Removing all these tests would be an option but we would lose the
ability to test the topologies.  Even though we just extract number of
sockets/cores/threads from all these directory trees.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

virfile: Add helpers for reading simple values

These helpers are doing just a read and covert the value, but they
properly size the read limit, handle additional whitespace characters,
and unify error reporting.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Remove some unneeded files

We are not using them at all and the directories are missing bunch of
files already.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

openvz: Ditch openvzGetNodeCPUs

There is particular function for this, there is no need to build whole
nodeinfo for it.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Separate syms based on files they are defined in

Commits eaf18f4c2bf1 and 86dd9fac0f1d separated util/host{cpu,mem}
stuff from nodeinfo, but did not adjust the syms file.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

vz: Do not use magic constants when building capabilities

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

tests: Fix indentation in virhostcputest

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

syms: Add one newline to make things consistent

It is everywhere else.  I even remember one of our scripts failing if
the newline is missing, but it doesn't happen currently.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

cpu: Don't use prefixes for no reason

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

vmware: Fix some initialization problems

Don't leak guest if adding it to virCapabilities fails.  Also return
NULL and not pointer to free'd object with zero references in such
case.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Expose virCapabilitiesFreeGuest

Guests are handled in callers, but if something goes wrong (when it
cannot be added to virCapabilities, for example), there's no way for
them to free it properly.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Introduce virCPUProbeHost

Both QEMU and bhyve are using the same function for setting up the CPU
in virCapabilities, so de-duplicate it, save code and time, and help
other drivers adopt it.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Add virNumaGetNodeCPUs to private syms

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

Fix build with GCC's static analysis

STREQ_NULLABLE returns true if both parameters are NULL.  And that's
not what we want here.  We just want to skop comparing source nodes
that don't have that info set.  The function wouldn't make much sense
with nodeName == NULL, so we don't need to check that.  Moreover, the
function's declaration uses ATTRIBUDE_NONNULL for nodeName, which not
only means that function expects the parameter not to be NULL, but
actually tells the compiler that it can optimize out the NULL checks.
That way it could end up calling strcmp on NULL (either nodeformat or
nodebacking).  GCC figures this out if libvirt is compiled with
lv_cv_static_analysis=yes, unfortunately not everyone uses that.

Caused by cbc6d53513568c9c9613b3eaae1c8a8230fd6aab.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>

qemu: stats: Display the block threshold size in bulk stats

Management tools may want to check whether the threshold is still set if
they missed an event. Add the data to the bulk stats API where they can
also query the current backing size at the same time.

qemu: block: Add code to fetch block node data by node name

To allow updating stats based on the node name, add a helper function
that will fetch the required data from 'query-named-block-nodes' and
return it in hash table for easy lookup.

util: json: Make function to free JSON values in virHash universal

Move the helper that frees JSON entries put into hash tables into the
JSON module so that it does not have to be reimplemented.

qemu: block: Add code to detect node names when necessary

Detect the node names when setting block threshold and when reconnecting
or when they are cleared when a block job finishes. This operation will
become a no-op once we fully support node names.

qemu: monitor: Extract the top level format node when querying disks

To allow matching the node names gathered via 'query-named-block-nodes'
we need to query and then use the top level nodes from 'query-block'.
Add the data to the structure returned by qemuMonitorGetBlockInfo.

tests: qemumonitorjson: Test node name detection on networked storage

tests: qemumonitorjson: Add relative image names for node name detection

oVirt uses relative names with directories in them. Test such
configuration. Also tests a snapshot done with _REUSE_EXTERNAL and a
relative backing file pre-specified in the qcow2 metadata.

tests: qemumonitorjson: Add case for two disks sharing a backing image

Since we have to match the images by filename a common backing image
will break the detection process. Add a test case to see that the code
correctly did not continue the detection process.

tests: qemumonitorjson: Add long backing chain test case for node name detection

tests: qemumonitorjson: Add test case for node name detection code

The code is rather magic so a test case will help making sure that
everything works well. The first case is a simple backing chain.

qemu: block: Add code to allow detection of auto-allocated node names

qemu for some time already sets node names automatically for the block
nodes. This patch adds code that attempts a best-effort detection of the
node names for the backing chain from the output of
'query-named-block-nodes'. The only drawback is that the data provided
by qemu needs to be matched by the filename as seen by qemu and thus
if two disks share a single backing store file the detection won't work.

This will allow us to use qemu commands such as
'block-set-write-threshold' which only accepts node names.

In this patch only the detection code is added, it will be used later.

qemu: monitor: Add monitor infrastructure for query-named-block-nodes

Add monitor tooling for calling query-named-block-nodes. The monitor
returns the data as the raw JSON array that is returned from the
monitor.

Unfortunately the logic to extract the node names for a complete backing
chain will be so complex that I won't be able to extract any meaningful
subset of the data in the monitor code.

qemu: capabilities: add capability for query-named-block-nodes qmp cmd

qemu: implement qemuDomainSetBlockThreshold

Add code to call the appropriate monitor command and code to lookup the
given disk backing chain member.

qemu: domain: Add helper to look up disk soruce by the backing store string

virsh: Implement 'domblkthreshold' command to call virDomainSetBlockThreshold

Add a simple wrapper which will allow to set the threshold for
delivering the event.

lib: Add API for setting the threshold size for VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD

The new API can be used to configure the threshold when
VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD should be fired.

qemu: process: Wire up firing of the VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD event

Bind it to qemu's BLOCK_WRITE_THRESHOLD event. Look up the disk by
nodename and construct the string to return.

qemu: domain: Add helper to generate indexed backing store names

The code is currently simple, but if we later add node names, it will be
necessary to generate the names based on the node name. Add a helper so
that there's a central point to fix once we add self-generated node
names.

qemu: domain: Add helper to lookup disk by node name

Looks up a disk and its corresponding backing chain element by node
name.

qemu: monitor: Add support for BLOCK_WRITE_THRESHOLD event

The event is fired when a given block backend node (identified by the
node name) experiences a write beyond the bound set via
block-set-write-threshold QMP command. This wires up the monitor code to
extract the data and allow us receiving the events and the capability.

lib: Introduce event for tracking disk backing file write threshold

When using thin provisioning, management tools need to resize the disk
in certain cases. To avoid having them to poll disk usage introduce an
event which will be fired when a given offset of the storage is written
by the hypervisor. Together with the API which will be added later, it
will allow registering thresholds for given storage backing volumes and
this event will then notify management if the threshold is exceeded.

util: storage: Add variables for node names into virStorageSource

'nodeformat' should be used for strings which describe the storage
format object, and 'nodebacking' for the actual storage object itself.

util: storage: Split out useful bits of virStorageFileParseChainIndex

The function has very specific semantics. Split out the part that parses
the backing store specification string into a separate helper so that it
can be reused later while keeping the wrapper with existing semantics.

Note that virStorageFileParseChainIndex is pretty well covered by the
test suite.

util: buffer: Add API to set indentation level to a given value

It will be useful to set indentation level to 0 after formatting a
nested structure rather than having to track the depth.

qemu: driver: Don't call qemuDomainDetermineDiskChain on block jobs

Our code calls it when starting or re-starting the domain or when
hotplugging the disk so there's nothing to be detected.

bhyve: add xhci tablet support

Along with video and VNC support, bhyve has introduced USB tablet
support as an input device. This tablet is exposed to a guest
as a device on an XHCI controller.

At present, tablet is the only supported device on the XHCI controller
in bhyve, so to make things simple, it's allowed to only have a
single XHCI controller with a single tablet device.

In detail, this commit:

 - Introduces a new capability bit for XHCI support in bhyve
 - Adds an XHCI controller and tabled support with 1:1 mapping
   between them
 - Adds a couple of unit tests

bhyve: helper function to probe hypervisor caps

There are a number of functions in bhyve_capabilities.c that probe
hypervisor capabilities by executing the bhyve(1) binary with the
specific device arugment, checking error message (if any) and setting
proper capability bit. As those are extremely similar, move this logic
into a helper function and convert existing functions to use that.

domaincapstest: add bhyve caps test

 * Extract filling bhyve capabilities from virBhyveDomainCapsBuild()
   into a new function virBhyveDomainCapsFill() to make testing
   easier by not having to mock firmware directory listing and
   hypervisor capabilities probing
 * Also, just presence of the firmware files is not sufficient
   to enable os.loader.supported, hypervisor should support UEFI
   boot too
 * Add tests to domaincapstest for the main caps possible flows:
    - when UEFI bootrom is supported
    - when video (fbus) is supported
    - neither of above is supported

schema: domaincaps: make machine element optional

Commit df769041c made the 'machine' element in domaincaps
optional. Update the schema to reflect that.

qemu: fix build with clang

qemuMigrationResetTLS() does not initialize 'ret' by default,
so when it jumps to 'cleanup' on error, the 'ret' variable will be
uninitialized, which clang complains about.

Set it to '-1' by default.

virpci: fix build on non-Linux

virPCIGetDeviceAddressFromSysfsLink() should return
virPCIDeviceAddressPtr, so return NULL in the stub instead of "-1".

docs: Add news entry for Migration using TLS

Signed-off-by: John Ferlan <jferlan@redhat.com>

qemu: Set up the migration TLS objects for source

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

If the migration flags indicate this migration will be using TLS,
then while we have connection in the Begin phase check and setup the
TLS environment that will be used by virMigrationRun during the Perform
phase for the source to configure TLS.

Processing adds an "-object tls-creds-x509,endpoint=client,..." and
possibly an "-object secret,..." to handle the passphrase response.

Then it sets the 'tls-creds' and possibly 'tls-hostname' migration
parameters.

The qemuMigrateCancel will clean up and reset the environment as it
was originally found.

Signed-off-by: John Ferlan <jferlan@redhat.com>