Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

CPU features unknown to a hypervisor will not be present in dataDisabled
even though the features won't naturally be enabled because.
Thus any features we asked for which are not in dataEnabled should be
considered disabled.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We already know from QEMU which CPU features will block migration. Let's
use this information to make a migratable copy of the host CPU model and
use it for updating guest CPU specification. This will allow us to drop
feature filtering from virCPUUpdate where it was just a hack.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This reverts commit 959e72d3 which was
pushed accidentally.

This will allow us to drop feature filtering from virCPUUpdate where it
was just a hack.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The caller can ask for a migratable CPU model by passing true for the
new parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We use the "vir" prefix pretty consistently in our
APIs, both external and internal, which made these
macros stood out.

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>

The test takes

  x86-cpuid-Something-guest.xml CPU (the CPU libvirt would use for
    host-model on a CPU described by x86_64-cpuid-Something.xml without
    talking to QEMU about what it supports on the host)

and updates it according to CPUID data from QEMU:

  x86_64-cpuid-Something-enabled.xml (reported as "feature-words"
    property of the CPU device)

and

  x86_64-cpuid-Something-disabled.xml (reported as "filtered-features"
    property of the CPU device).

The result is compared to

  x86_64-cpuid-Something-json.xml (the CPU libvirt would use as
    host-model based on the reply from query-cpu-model-expansion).

The comparison is a bit tricky because the *-json.xml CPU contains fewer
disabled features. Only the features which are included in the base CPU
model, but listed as disabled in *.json will be disabled in *-json.xml.
The CPU computed by virCPUUpdateLive from the test data will list all
features present in the host's CPUID data and not enabled in *.json as
disabled. The cpuTestUpdateLiveCompare function checks that the computed
and expected sets of enabled features match.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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: NJiri Denemark <jdenemar@redhat.com>

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: NJiri Denemark <jdenemar@redhat.com>

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

All existing Haswell CPUID data were gathered from CPUs with broken TSX.
Let's add new data for Haswell with correct TSX implementation.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

The original test didn't use family/model numbers to make better
decisions about the CPU model and thus mis-detected the model in the two
cases which are modified in this commit. The detected CPU models now
match those obtained from raw CPUID data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

While "x86" is a CPU sub driver name, it is not a recognized name of any
architecture known to libvirt. Let's use "x86_64" prefix which can be
used with virArch APIs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new API is called virCPUDataFree. Individual CPU drivers are no
longer required to implement their own freeing function unless they need
to free architecture specific data from virCPUData.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

PPC driver needs to convert POWERx_v* legacy CPU model names into POWERx
to maintain backward compatibility with existing domains. This patch
adds a new step into the guest CPU configuration work flow which CPU
drivers can use to convert legacy CPU definitions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The API is no longer used anywhere else since it was replaced by a much
saner work flow utilizing new APIs that work on virCPUDefPtr directly:
virCPUCompare, virCPUUpdate, and virCPUTranslate.

Not testing the new work flow caused some bugs to be hidden. This patch
reveals them, but doesn't attempt to fix them. To make sure all test
still pass after this patch, all affected test results are modified to
pretend the tests succeeded. All of the bugs will be fixed in the
following commits and the artificial modifications will be reverted.

The following is the list of bugs in the new CPU model work flow:

- a guest CPU with mode='custom' and missing <vendor/> gets the vendor
  copied from host's CPU (the vendor should only be copied to host-model
  CPUs):
    DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL)
    DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL)
    DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0)

- when a guest CPU with mode='custom' needs to be translated into
  another model because the original model is not supported by a
  hypervisor, the result will have its vendor set to the vendor of the
  original CPU model as specified in cpu_map.xml even if the original
  guest CPU XML didn't contain <vendor/>:
    DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0)
    DO_TEST_GUESTCPU("x86", "host", "guest", models, 0)
    DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX",
                     haswell, 0)

- legacy POWERx_v* model names are not recognized:
    DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Now that all tests pass NULL as the preferred model, we can just drop
that test parameter.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In some cases preferred model doesn't really do anything since the
result remains the same even if it is removed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Using a preferred model for guest CPUs with forbidden fallback masks a
bug in the code. It would just happily use another CPU model supported
by a hypervisor even though it is explicitly forbidden in the CPU XML.

This patch temporarily changes the expected result to -2, which is used
when the result XML file cannot be found (but it was supposed not to be
found since the tested API should have failed). The result will be
switched back to -1 few commits later when the original bug gets fixed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Using a preferred CPU model which is not in the list of CPU models
supported by a hypervisor does not make sense.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Guest CPUs with match='minimum' should always be updated to match host
CPU model. Trying to get different results by supplying preferred models
does not make sense.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new name is virCPUDataParse.
Signed-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>

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>

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>

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

In 3704b900 ("tests: Add CPU detection tests"), a macro called
DO_TEST_CPUID_JSON is added. But it took only two arguments when QEMU
or YAJL is not set.

Fix it by adding a third argument. Shouldn't have any effect because
that macro compiles to nothing.
Signed-off-by: NWei Liu <wei.liu2@citrix.com>

The actual CPU model in the data files is Penryn which makes the file
name look rather strange. Well, one of them contains Nehalem, but that's
a bug which will be fixed soon.
Signed-off-by: NJiri Denemark <jdenemar@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>

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

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