We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseString.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some callers might want to pass yet another pointer to opaque
data to post parse callbacks. The driver generic one is not
enough because two threads executing post parse callback might
want to see different data (e.g. domain object pointer that
domain def belongs to).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Based upon a patch from Chen Hanxiao <chenhanxiao@gmail.com>, rather than
need to call virFindFileInPath twice, let's just save the path and pass it
along with the compressed type. (NB: the second call would be in virExec as
called from virCommandRunAsync which is called from qemuMigrationToFile
using the argument 'compressor' which up to this point would be the string
from the cfg file that isn't the fully qualified path).

Since we now have the path, we can remove qemuCompressProgramName which
would return NULL or the string representation of the compress type.

There's only one caller and the code is duplicitous just converting the
recently converted cfg image name back into it's string value in order to
get/find the path to the image.  A subsequent patch can return this path.

Let's do some more code reuse - there are 3 other callers that care to
check/get the compress program. Each of those though cares whether the
requested cfg image is valid and exists. So, add a parameter to handle
those cases.

NB: We won't need to initialize the returned value in the case where
the cfg image doesn't exist since the called program will handle that.

Add a new parameter 'styleFormat' to be used when printing the
warning message so that it's "clearer" what style of compression
call caused the error. Add that style to both messages as a paremter.

Also a VIR_WARN error message doesn't need to be translated
 (e.g. inside _()), so remove the need for the translation.

There's only one caller now anyway... Besides it's just a shell for
getting the compress type.  Subsequent patches will return the path
to the compression program.

Split out the guts of getCompressionType to perform the same functionality
in the new helper program with a subsequent patch goal to be reusable for
other callers making similar checks/calls to ensure the compression type
is valid and that the compression program cannot be found.

Rather than calling getCompressionType from each of the callers, just call
it from doCoreDump.  A subsequent patch will be adjust the code even more.

A subsequent patch will adjust the 3 callers to just call from doCoreDump.

Both cpuCompare* APIs are renamed to virCPUCompare*. And they should now
work for any guest CPU definition, i.e., even for host-passthrough
(trivial) and host-model CPUs. The implementation in x86 driver is
enhanced to provide a hint about -noTSX Broadwell and Haswell models
when appropriate.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

Our internal APIs mostly use virArch rather than strings. Switching
cpuGetModels to virArch will save us from unnecessary conversions in the
future.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Calling virDomainGetEmulatorPinInfo on a live VM with automatic NUMA
pinning and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning
data in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.

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

Calling virDomainGetVcpuPinInfo on a live VM with automatic NUMA pinning
and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning data
in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.

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

Checking if a domain's definition or if it is active before we got a job
is pointless since the domain might have changed in the meantime.

Luckily libvirtd didn't crash when the API tried to talk to an inactive
domain:

debug : qemuDomainObjBeginJobInternal:2914 : Started job: modify
    (async=none vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEnterMonitorInternal:3137 : Entering monitor
    (mon=(nil) vm=0x7f8f340140c0 name=ble)
warning : virObjectLock:319 : Object (nil) ((unknown)) is not a
    virObjectLockable instance
debug : qemuMonitorOpenGraphics:3505 : protocol=spice fd=27
    fdname=graphicsfd skipauth=1
error : qemuMonitorOpenGraphics:3508 : invalid argument: monitor must
    not be NULL
debug : qemuDomainObjExitMonitorInternal:3160 : Exited monitor
    (mon=(nil) vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEndJob:3068 : Stopping job: modify (async=none
    vm=0x7f8f340140c0 name=ble)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Apparently, some management applications use the following code
pattern when waiting for a block job to finish:

  while (1) {
    virDomainGetBlockJobInfo(dom, disk, info, flags);

    if (info.cur == info.end)
        break;

    sleep(1);
  }

Problem with this approach is in its corner cases. In case of
QEMU, libvirt merely pass what has been reported on the monitor.
However, if the block job hasn't started yet, qemu reports cur ==
end == 0 which tricks mgmt apps into thinking job is complete.

The solution is to mangle cur/end values as described here [1].

1: https://www.redhat.com/archives/libvir-list/2016-September/msg00017.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Even though we merely just pass to users whatever qemu provided
on the monitor, we still do some translation. For instance we
turn bytes into mebibytes, or fix job type if needed. However, in
the future there is more fixing to be done so this code deserves
its own function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

At this point it's guaranteed that 'persistentDef' is non-NULL so we
don't need to check it again.

When hot-adding vcpus qemu needs to allocate some structures in the DMA
zone which may be outside of the numa pinning. Extract the code doing
this in a set of helpers so that it can be reused.

With current perf framework, this patch adds support and documentation
for more perf events, including cache misses, cache references, cpu cycles,
and instructions.
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>

Remove the unnecessary switch since all VIR_PERF_EVENT* values are fetched

This patch rename qemuDomainGetStatsPerfRdt() to
qemuDomainGetStatsPerfOneEvent()
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>

Since the domain lock is not held during preparation of an external XML
config, it is possible that the value can change resulting in unexpected
failures during ABI consistency checking for some save and migrate
operations.

This patch adds a new flag to skip the checking of the cur_balloon value
and then sets the destination value to the source value to ensure
subsequent checks without the skip flag will succeed.

This way it is protected from forges and is keeped up to date too.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Setting vcpu count when cpu topology is specified may result into an
invalid configuration. Since the topology can't be modified, reject the
setting if it doesn't match the requested topology. This will allow
fixing the topology in case it was broken.

Partially fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1370066

ce43cca0 refactored the helper to prepare it for sparse topologies but
forgot to fix the iterator used to fill the structures. This would
result into a weirdly sparse populated array and possible out of bounds
access and crash once sparse vcpu topologies were allowed.

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

This patch removes the old vcpu unplug code completely and replaces it
with the new code using device_del. The old hotplug code basically never
worked with any recent qemu and thus is useless.

As the new code is using device_del all the implications of using it
are present. Contrary to the device deletion code, the vcpu deletion
code fails if the unplug request is not executed in time.

To allow unplugging the vcpus, hotplugging of vcpus on platforms which
require to plug multiple logical vcpus at once or plugging them in an
arbitrary order it's necessary to use the new device_add interface for
vcpu hotplug.

This patch adds support for the device_add interface using the old
setvcpus API by implementing an algorithm to select the appropriate
entities to plug in.

Similarly to devices the guest may allow unplug of the VCPU if libvirt
is down. To avoid problems, refresh the vcpu state on reconnect. Don't
mess with the vcpu state otherwise.

s/libvirt.c/libvirt-domain.c
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

All other modes of qemuDomainSetVcpusFlags have helpers so finish the
work by splitting the regular code into a new function.

This patch also touches up the coding (spacing) style.

The live code does ugly things. Contain it in a separate function.

Setting of the maximum vcpu count is slightly semantically different
thus split it into a self-contained func.

Mention whether it was the live or persistent definition which caused an
error reported and explicitly error out in case when attempting to set
maximum vcpu count for a live domain.

Call the vcpu thread info validation separately to decrease complexity
of returned values by qemuDomainRefreshVcpuInfo.

This function now returns 0 on success and -1 on error. Certain
failures of qemu to report data are still considered as success. Any
error reported now is fatal.