Move QEMU_DRIVE_HOST_PREFIX into the qemu_alias.c to dissuade future
callers from using it. Create qemuAliasDiskDriveSkipPrefix in order
to handle the current consumers that desire to check if an alias has
the drive- prefix and "get beyond it" in order to get the disk alias.

Since we already have a function that will generate the drivestr from
the alias, let's use it and remove the qemuDeviceDriveHostAlias.

Move the QEMU_DRIVE_HOST_PREFIX definition into qemu_alias.h

Also alter qemuAliasFromDisk to use the QEMU_DRIVE_HOST_PREFIX instead
of "drive-%s".

Rather than pass the disks[i]->info.alias to qemuMonitorSetDrivePassphrase
and then generate the "drive-%s" alias from that, let's use qemuAliasFromDisk
prior to the call to generate the drive alias and then pass that along
thus removing the need to generate the alias from the monitor code.

QEMU reports timestamp along with other memory statistics, but this information is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in qemu_monitor_text.c.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

'memtotal' in virtio drivers and qemu corresponds to 'available' in libvirt.
Because of that, 'stat-available-memory' is renamed into 'usable'.
Balloon statistics are not reported in hrf, so no modifications are made in qemu_monitor_text.c.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

Commit ce745914 introduced detection of actual video ram sizes to fix migration
if QEMU decide to modify the values provided by libvirt.  This works perfectly
for domains with number of video devices up to two.

If there are more than two video devices in the guest all the secondary devices
in the XML will have the same memory values.  This is because our current code
search for QOM device path only by the device type name and all the secondary
video devices has the same name "qxl".

This patch introduces a new search function that will try to search a QOM device
path using also device's alias if the alias is available. After that it will
fallback to the old recursive code if the alias search found no results.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358728Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

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

We should not require any parameters to be present. After all we have
the *_set bools to express that some parameters were not set.
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>

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

We have the code for attaching redirdevs for ages now.
Unfortunately, our monitor code that handles talking to the qemu
process was missing a little piece of code that actually enabled
the feature.

BTW: it really is called "type" on the monitor, even though it's
called "name" on the cmd line. Don't ask.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. This patch prepares the x86 CPU
driver code for the new 'ecx_in' CPUID parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virCPUData, virCPUx86Feature, and virCPUx86Model all contained a pointer
to virCPUx86Data, which was not very nice since the real CPUID data were
accessible by yet another pointer from virCPUx86Data. Moreover, using
virCPUx86Data directly will make static definitions of internal CPU
features a bit easier.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This patch splits qemuMonitorJSONGetCPUx86Data in three functions:

- qemuMonitorJSONCheckCPUx86 checks if QEMU supports reporting CPUID
  features for a guest CPU

- qemuMonitorJSONParseCPUx86Features parses CPUID features from a JSON
  array

- qemuMonitorJSONGetCPUx86Data gets the requested guest CPU property
  from QOM and uses qemuMonitorJSONParseCPUx86Features to parse it
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. Let's rename 'function' to
'eax_in' in preparation for adding 'ecx_in'.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit b4a5fd95 introduced vram64 attribute for QXL video device but
there were two issues.  Only function
qemuMonitorJSONUpdateVideoVram64Size should update the vram64 attribute
and also the value is in MiB, not in B.
Signed-off-by: NPavel Hrdina <phrdina@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 whether a given drive has a tray and whether there is no image
inserted.

Negative logic for the image insertion is chosen so that the flag is set
only if we are certain of the fact.

It was only called for QEMUs without QEMU_CAPS_DEVICE,
which we no longer support.

Recent adjustments to the code produced a litany of coverity false
positives, but only because the "standard" procedure of setting a
variable to NULL after it was assigned to something else and keeping
the *Free/*FREE call in the cleanup path wasn't kept. So this patch
makes those adjustments (assign variable to NULL and remove the if
'ret < 0' condition to clean it up).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In 7884d089 I've started to refactor qemu_monitor_json.c.
Thing is, it's current structure is nothing like the rest of our
code. The @ret variable is rewritten all the time, if()-s are
nested instead of using goto and so on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

In majority of our functions we have this variable @ret that is
overwritten a lot. In other areas of the code we use 'goto
cleanup;' just so that this wouldn't happen. But here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In these functions I'm fixing here, we do call
qemuMonitorJSONCheckError() followed by another check if qemu
reply contains 'return' object. If it wouldn't, the former
CheckError() function would error out and the flow would not even
get to the latter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Usually, the flow in this area of the code is as follows:

qemuMonitorJSONMakeCommand()
qemuMonitorJSONCommand()
qemuMonitorJSONCheckError()
parseReply()

But in this function, for some reasons, the last two steps were
swapped. This makes no sense.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Code was obsoleted by using -device.

QEMU introduced the query-gic-capabilities QMP command
with commit 4468d4e0f383: use the command, if available,
to probe available GIC capabilities.

The information obtained is stored in a virQEMUCaps
instance, and will be later used to fill in a
virDomainCaps instance.

Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

The event is emitted on ACPI OSPM Status Indication events.

ACPI standard documentation describes the method as:

This object is an optional control method that is invoked by OSPM to
indicate processing status to the platform. During device ejection,
device hot add, or other event processing, OSPM may need to perform
specific handshaking with the platform. OSPM may also need to indicate
to the platform its inability to complete a requested operation; for
example, when a user presses an ejection button for a device that is
currently in use or is otherwise currently incapable of being ejected.
In this case, the processing of the ACPI Eject Request notification by
OSPM fails. OSPM may indicate this failure to the platform through the
invocation of the _OST control method. As a result of the status
notification indicating ejection failure, the platform may take certain
action including reissuing the notification or perhaps turning on an
appropriate indicator light to signal the failure to the user.

qemu won't ever add those functions directly to QMP. They will be
replaced with 'blockdev-add' and 'blockdev-del' eventually. At this time
there's no need to keep the stubs around.

Additionally the drive_del stub in JSON contained dead code in the
attempt to report errors. (VIR_ERR_OPERATION_UNSUPPORTED was never
reported). Since the text impl does have the same message it is reported
anyways.

QEMU changed the error message to:

        "Tray of device 'drive-sata0-0-1' is not open"

and they may change the error massage in the future.

This updates the code to not depend on the text from the error message
but only on error itself.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NCristian Klein <cristiklein@gmail.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Migration enters "postcopy-active" state after QEMU switches to
post-copy and pauses guest CPUs. From libvirt's point of view this state
is similar to "completed" because we need to transfer guest execution to
the destination host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This attribute is used to extend secondary PCI bar and expose it to the
guest as 64bit memory.  It works like this: attribute vram is there to
set size of secondary PCI bar and guest sees it as 32bit memory,
attribute vram64 can extend this secondary PCI bar.  If both attributes
are used, guest sees two memory bars, both address the same memory, with
the difference that the 32bit bar can address only the first part of the
whole memory.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Extract out the qemuParseCommandLine{String|Pid} into their own
separate module - taking with it all the various static functions.

Causes a ripple effect with a few other modules to include the
new qemu_parse_command.h.

Narrowed down the list of #include's in the split out module to
those that are necessary for build.

The corresponding event in QEMU is called MIGRATION_PASS.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

memory_dirty_rate corresponds to dirty-pages-rate in QEMU and
memory_iteration is what QEMU reports in dirty-sync-count.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>