Re: [Qemu-devel] [Patch v1 24/29] qmp: add QMP interface "query-cpu-model-expansion"

[David Hildenbrand]

> On Tue, Aug 02, 2016 at 05:04:05PM +0200, David Hildenbrand wrote:
> [...]
> > >   
> > > > +#          model can be used by tooling without having to specify a
> > > > +#          compatibility machine - e.g. when displaying the "host" 
> > > > model.
> > > > +#          All static CPU models are migration-safe.    
> > > 
> > > This is cool. Unfortunately we are not going to support it in x86
> > > very soon because we don't have any static CPU models.  
> > 
> > Well, it's all about finding a minimum set of features that one can work 
> > with.
> > I assume e.g. a Phenom also always has a minimum set of features?  
> 
> We could have a very minimal CPU model that is static in x86,
> yes. We just need to find out "how minimal" we can really make
> it.

Right. Basically, on s390x we have two types of features
1) hypervisor managed
2) non-hypervisor managed

Meaning the hypervisor can blindly forward 2), but needs special implementation
for 1). This implies that old releases of an hypervisor will only show 2) but
not 1).

We can therefore move all 2) that are made public (~99%) into the minimum model
+ some very old 1) that are always expected to be around nowadays.

Actually going below the minimum model is possible on s390x, could just happen
that e.g. Linux will not boot anymore.

But the question is, if static CPU models for x86 are really needed. I assume
you only make veeeery little changes to these models, so showing them
without a compatibility machine should almost always give the same result. And
that's the main difference to s390x. The other one is obviously that we have
much more feature variance, depending under which hypervisor (LPAR/KVM/z/VM)
and version we're running.

> 
> >   
> > >   
> > > > +#
> > > > +# @full: Expand all properties. The produced model is not guaranteed 
> > > > to be
> > > > +#        migration-safe, but allows tooling to get an insight and work 
> > > > with
> > > > +#        model details.    
> > > 
> > > I wonder if we really need to document it broadly as "not
> > > guaranteed to be migration-safe". The returned data will be
> > > migration-safe (but not static) if the CPU model being expanded
> > > is migration-safe, won't it?  
> > 
> > Actually I don't think so.
> > Imagine expanding host: featA=true, featB=false  
> 
> In this case, "host" is not migration-safe, so the results will
> not be migration-safe.

Yes, so I'll keep this remark for now.

> > > > +#
> > > > +# s390x supports expanding of all CPU models with all expansion types. 
> > > > Other
> > > > +# architectures are not supported yet.    
> > > 
> > > I think this paragraph is likely to get obsolete very soon (as
> > > people may forget to update it when implementing the new
> > > interface on other architectures). Also, the paragraph is not
> > > true until patch 27/29 is applied.
> > > 
> > > Maybe write it as "Some architectures may not support all
> > > expansion types".  
> > 
> > Agreed. And most likely x86 won't support expanding all CPU models I 
> > assume?  
> 
> It will probably support expanding all CPU models in the same way
> (when using "full").
> 

Cool! Thanks!

David