If calling query-cpu-model-expansion on the 'host'/'max' CPU model with
'migratable' property set to false succeeds, we know QEMU is able to
tell us which features would disable migration. Thus we can mark all
enabled features as migratable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

QEMU is able to tell us whether a CPU feature would block migration or
not. This patch adds support for storing such features in
qemuMonitorCPUModelInfo.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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.

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.

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

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.

Add the fields to support setting tls-creds and tls-hostname during
a migration (either source or target). Modify the query migration
function to check for the presence and set the field for future
consumers to determine which of 3 conditions is being met (NULL,
present and set to "", or present and sent to something). These
correspond to qemu commit id '4af245dc3' which added support to
default the value to "" and allow setting (or resetting) to ""
in order to disable. This reset option allows libvirt to properly
use the tls-creds and tls-hostname parameters.

Modify code paths that either allocate or use stack space in order
to call qemuMigrationParamsClear or qemuMigrationParamsFree for cleanup.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The 'mon' argument validity is checked in the QEMU_CHECK_MONITOR for the
following functions, so they don't need the NONNULL on their prototype:

qemuMonitorUpdateVideoMemorySize
qemuMonitorUpdateVideoVram64Size
qemuMonitorGetAllBlockStatsInfo
qemuMonitorBlockStatsUpdateCapacity
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '85af0b80' added a 'timeout' as the 4th parameter to
qemuMonitorOpen, but neglected to update the ATTRIBUTE_NONNULL(4)
to be (5) for the cb parameter.

qemuMonitorGetGuestCPU can now optionally create CPU data from
filtered-features in addition to feature-words.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There were couple of reports on the list (e.g. [1]) that guests
with huge amounts of RAM are unable to start because libvirt
kills qemu in the initialization phase. The problem is that if
guest is configured to use hugepages kernel has to zero them all
out before handing over to qemu process. For instance, 402GiB
worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we
do not want to make the timeout for connecting to monitor
configurable, we have to teach libvirt to count with this
fact. This commit implements "1s per each 1GiB of RAM" approach
as suggested here [2].

1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html
2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

The static CPU model expansion is designed to return only canonical
names of all CPU properties. To maintain backwards compatibility libvirt
is stuck with different spelling of some of the features, but we need to
use the full expansion to get the additional spellings. In addition to
returning all spelling variants for all properties the full expansion
will contain properties which are not guaranteed to be migration
compatible. Thus, we need to combine both expansions. First we need to
call the static expansion to limit the result to migratable properties.
Then we can use the result of the static expansion as an input to the
full expansion to get both canonical names and their aliases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

While query-cpu-model-expansion returns only boolean features on s390,
but x86_64 reports some integer and string properties which we are
interested in.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

Add support to read/parse the iotune group setting for qemu.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

QEMU 2.8.0 adds support for unavailable-features in
query-cpu-definitions reply. The unavailable-features array lists CPU
features which prevent a corresponding CPU model from being usable on
current host. It can only be used when all the unavailable features are
disabled. Empty array means the CPU model can be used without
modifications.

We can use unavailable-features for providing CPU model usability info
in domain capabilities XML:

    <domainCapabilities>
      ...
      <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'>
          <model fallback='allow'>Skylake-Client</model>
          ...
        </mode>
        <mode name='custom' supported='yes'>
          <model usable='yes'>qemu64</model>
          <model usable='yes'>qemu32</model>
          <model usable='no'>phenom</model>
          <model usable='yes'>pentium3</model>
          <model usable='yes'>pentium2</model>
          <model usable='yes'>pentium</model>
          <model usable='yes'>n270</model>
          <model usable='yes'>kvm64</model>
          <model usable='yes'>kvm32</model>
          <model usable='yes'>coreduo</model>
          <model usable='yes'>core2duo</model>
          <model usable='no'>athlon</model>
          <model usable='yes'>Westmere</model>
          <model usable='yes'>Skylake-Client</model>
          ...
        </mode>
      </cpu>
      ...
    </domainCapabilities>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We don't need to call qemuMonitorGetCPUInfo which is very inefficient to
get data required to update the vcpu 'halted' state.

Add a monitor helper that will retrieve the halted state and return it
in a bitmap so that it can be indexed easily.

Storing of the ID will allow simpler extraction of data present only in
query-cpus without the need to call qemuMonitorGetCPUInfo in statistics
paths.

Call 'query-qmp-schema' and store the returned types in a hash table
keyed by the 'name' field so that the capabilities code can traverse it.

Add support for a duration/length for the bps/iops and friends.

Modify the API in order to add the "blkdeviotune." specific definitions
for the iotune throttling duration/length options

    total_bytes_sec_max_length
    write_bytes_sec_max_length
    read_bytes_sec_max_length
    total_iops_sec_max_length
    write_iops_sec_max_length
    read_iops_sec_max_length

Extended the qemuMonitorCPUInfo with a halted flag. Extract the halted
flag for both text and JSON monitor.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Return whether a vcpu entry is hotpluggable or online so that upper
layers don't have to infer the information from other data.

Advantage is that this code can be tested by unit tests.

When migration fails, we need to poke QEMU monitor to check for a reason
of the failure. We did this using query-migrate QMP command, which is
not supposed to return any meaningful result on the destination side.
Thus if the monitor was still functional when we detected the migration
failure, parsing the answer from query-migrate always failed with the
following error message:

    "info migration reply was missing return status"

This irrelevant message was then used as the reason for the migration
failure replacing any message we might have had.

Let's use harmless query-status for poking the monitor to make sure we
only get an error if the monitor connection is broken.

https://bugzilla.redhat.com/show_bug.cgi?id=1374613Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For hotplug purposes it's necessary to retrieve data using
query-hotpluggable-cpus while the old query-cpus API report thread IDs
and order of hotplug.

This patch adds code that merges the data using a rather non-trivial
algorithm and fills the data to the qemuMonitorCPUInfo structure for
adding to appropriate place in the domain definition.

Add support for retrieving information regarding hotpluggable cpu units
supported by qemu. Data returned by the command carries information
needed to figure out the granularity of hotplug, the necessary cpu type
name and the topology information.

Note that qemu doesn't specify any particular order of the entries thus
it's necessary sort them by socket_id, core_id and thread_id to the
order libvirt expects.

To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.

QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.

When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.

Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.

The function will gradually add more returned data. Return a struct for
every vCPU containing the data.

Rather than formatting a string and splitting it back to a JSON object
add API that will take a JSON object directly.

Commit 4a585a88 introduced searching QOM device path by alias, let's use it for
memballoon too.  This may speedup the search because in most cases we will find
the correct QOM device path directly by using alias without the need for the
recursion code.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The caller is already aware that the params are missing and the
extractor is ignoring the missing ones so the parameter isn't necessary.

Extract information for all disks and update tray state and source only
for removable drives. Additionally store whether a drive is removable
and whether it has a tray.