Re: [libvirt] [Qemu-devel] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion
On Mon, Dec 05, 2016 at 07:13:36PM +0100, David Hildenbrand wrote:
> > 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)
Your point is valid, and the field is probably not strictly
necessary. But considering that the interface is not trivial, I
think it is a good thing to have extra metadata that can help
clients validate their assumptions. Even if it's useful in
practice only for debugging, it would be a good reason to add it,
IMO.
I first considered only updating the documentation to make the
guarantees explicit (so people won't assume that type=full
expansion is always a superset of static, or that type=static
expansion is always precise/ABI-compatible and will never lose
any features). But then I thought that returning extra metadata
would help people using the interface (and help us validate the
implementation on the test script).
Anyway, the next version of this series will have the new fields
added by a separate patch. This way we can evaluate and discuss
the interface changes separately.
--
Eduardo