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

[David Hildenbrand]

>> 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"?
>
> I didn't have any specific use case in mind. My main worry is to
> avoid letting management software make any assumptions about the
> returned data. If we don't add an explicit "static" field, a
> client might make some wrong assumptions just because some
> conditions are known to be always true on existing
> implementations. e.g.: a client could incorrectly assume that
> "query-cpu-model-expansion type=full" of a migration-safe model
> would always be static.

I think "migration-safe" makes sense, as the doc currently states for
"@full": "The produced model is not guaranteed to be migration-safe".

For static expansion, this information is somewhat superfluous, as
"static CPU models are migration-safe", but it doesn't hurt. (and this
is also what you properly documented :) )

But I don't think that "static" will be of any use. If you want a
static model, go for "static" expansion. (I don't really see any use
case here, but if you do, keep it)


>> 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).
>
> I meant a kernel binary, above. On x86, there are existing test
> cases on the autotest repository that run a very small kernel[1]
> that simply dumps CPUID data to the serial console. We could
> reuse it, or we could add a CPUID command to the qtest protocol.
> I'm not sure what's the best solution.
>
> We can try to use a similar approach on s390x to reuse code in
> the test script, but we can add arch-specific code to it if
> necessary.

Ah, alright, so I wasn't aware of that because there is no autotest for
s390x (at least not that I know of ;) ). Thanks for the hint.

>
> [1] https://github.com/autotest/tp-qemu/tree/master/qemu/deps/cpuid/src
>


-- 

David