enum types are unsigned and the qemuGetCompressionProgram
function can return -1 on error. It is therefore inappropriate
to return an enum type. This fixes a build error where the
internal 'ret' variable was used in a comparison with -1

../../src/qemu/qemu_driver.c: In function 'qemuGetCompressionProgram':
../../src/qemu/qemu_driver.c:3280:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
../../src/qemu/qemu_driver.c:3289:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
cc1: all warnings being treated as errors
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

When creating a copy of virDomainDef we save ourselves the
trouble of writing deep-copy functions and just format and parse
back domain/device XML. However, the XML we are parsing was
already fully formatted - there is no reason to run post parse
callbacks (which fill in blanks - there are none!).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is an internal flag that prevents our two entry points to
XML parsing (virDomainDefParse and virDomainDeviceDefParse) from
running post parse callbacks. This is expected to be used in
cases when we already have full domain/device XML and we are just
parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Just like we did two commits ago, don't try to fetch capabilities
for non-existing binary. Re-use the ones we have for running
domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We can't rely on def->emulator path. It may be provided by user
as we give them opportunity to provide their own XML for
migration. Therefore the path may point to just whatever binary
(or even to a non-existent file). Moreover, this path is meant
for destination, but the capabilities lookup is done on source.
What we can do is to assume same capabilities for post parse
callbacks as the running domain has. They will be used just to
add some default models/controllers/devices/... anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Just like virDomainDefPostParseCallback has gained new
parseOpaque argument, we need to follow the logic with
virDomainDeviceDefPostParse.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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>

We want to pass the proper opaque pointer instead of NULL to
virDomainDefParseXML and subsequently virDomainDefPostParse 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>

Remove unnessary translated message marker _()
for the VIR_WARN messages.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.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.

If passing an empty usbdevice_list to libxl, qemu will always get an
-usb parameter for HVM guests with only non-USB input devices. This
causes qemu to crash when passing pvusb device on HVM guests.

The solution is to allocate the list only when an item to put in it
is found.

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

Commit id 'ce61c164' indented wrong - not sure how I did that...

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

It really doesn't belong to the generic CPU driver.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Storing the updated CPU definition in the live domain definition saves
us from having to update it over and over when we need it. Not to
mention that we will soon further update the CPU definition according to
QEMU once it's started.

A highly wanted side effect of this patch, libvirt will pass all CPU
features explicitly specified in domain XML to QEMU, even those that are
already included in the host model.

This patch should fix the following bugs:
    https://bugzilla.redhat.com/show_bug.cgi?id=1207095
    https://bugzilla.redhat.com/show_bug.cgi?id=1339680
    https://bugzilla.redhat.com/show_bug.cgi?id=1371039
    https://bugzilla.redhat.com/show_bug.cgi?id=1373849
    https://bugzilla.redhat.com/show_bug.cgi?id=1375524
    https://bugzilla.redhat.com/show_bug.cgi?id=1377913Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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>

The function is similar to virCPUDataCheckFeature, but it works directly
on CPU definition rather than requiring it to be transformed into CPU
data first.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

To match our coding style and to provide better debug and error
messages.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

The API is supposed to make sure the provided CPU definition does not
use a CPU model which is not supported by the hypervisor (if at all
possible, of course).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Keeping nfeatures_max set to 0 while nfeatures > 0 and some features are
already stored in features array is just asking for problems once we
want to add a new feature into the array.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The reworked API is now called virCPUUpdate and it should change the
provided CPU definition into a one which can be consumed by the QEMU
command line builder:

    - host-passthrough remains unchanged
    - host-model is turned into custom CPU with a model and features
      copied from host
    - custom CPU with minimum match is converted similarly to host-model
    - optional features are updated according to host's CPU
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function checks CPUID data for a given feature.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

x86ModelFromCPU is used to provide CPUID data for features matching
@policy. This patch allows callers to set @policy to -1 to get combined
CPUID for all CPU features (including those implicitly provided a CPU
model) specified in CPU def.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>