[libvirt] [Qemu-devel] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion

[David Hildenbrand]

Am 02.12.2016 um 22:17 schrieb Eduardo Habkost:
> This series implements query-cpu-model-expansion on target-i386.
>
> QAPI / interface changes
> ------------------------
>
> When implementing this, I have noticed that the "host" CPU model
> in i386 includes some migration-unsafe features that can't be
> translated to any migration-safe representation: "pmu", and
> "host-cache-info".
>
> To be able to handle the migration-unsafe features, I have
> extended the query-cpu-model-expansion definition to be clear
> about what happens to those features when the CPU model is
> expanded (in short: static expansion removes them, full expansion
> keeps them).

I think this makes sense. The important part is to really keep static 
expansion static :)

>
> I also added "static" and "migration-safe" fields to the return
> value of query-cpu-model-expansion, so callers can know if the
> the expanded representation is static and migration-safe.

Is static really needed? I can understand why migration-safe might be
of interest, but can't see how "static" could help (I mean we have
static expansion for this purpose). Do you have anything special in
mind regarding exposing "static"?

>
> Test code
> ---------
>
> I have added a Python test script for the feature, that will try
> multiple combinations of the expansion operation, and see if the
> returned data keeps matches some constratins.
>
> The test script works with the s390x query-cpu-model-expansion
> command, except that: 1) I couldn't test it with KVM; 2) qtest.py
> error handling when QEMU refuses to run is unreliable (so the
> script needs runnability information to be availble in TCG mode,
> too, to skip not-runnable CPU models and avoid problems).

Everything except "host" should behave completely the same on s390x
with or without KVM being active. So with !KVM tests we can already
cover most of the interesting parts. Thanks for taking care of s390x.

>
> Future versions of the test script could run a arch-specific
> CPUID-dump guest binary, and validate data seen by the guest
> directly. While we don't do that, the script validates all QOM
> properties on the CPU objects looking for unexpected changes. At
> least in the case of x86, the QOM properties will include lots of
> the CPUID data seen by the guest, giving us decent coverage.

Something like that would be cool. Unfortunately, e.g. on s390x some 
CPUID-like data (e.g. STFL(E) and SCP info) is only available from
kernel space. So we can't simply run a user space script. However,
something like a kernel module would be possible (or even something like 
the s390x pc-bios to simply read and dump the data).


-- 

David