qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups


From: Eduardo Habkost
Subject: Re: [PATCH v2 2/2] s390x/cpumodel: Introduce dynamic feature groups
Date: Fri, 29 Nov 2019 16:33:17 -0300

On Tue, Nov 26, 2019 at 03:07:32PM +0100, David Hildenbrand wrote:
> On 26.11.19 13:59, Christian Borntraeger wrote:
> > re-adding ccs from the cover-letter
> > 
> >>>> On 25.11.19 18:20, David Hildenbrand wrote:
> >>>>
> >>>> As soon as dynamic feature groups are used, the CPU model becomes
> >>>> migration-unsafe. Upper layers can expand these models to migration-safe
> >>>> and static variants, allowing them to be migrated.
> >>>
> >>> I really dislike that. I am trying to get rid of the unsafe variants 
> >>> (e.g. now
> >>> defaulting to host-model instead of host-passthrough). I do not want to 
> >>> give
> >>> users new ways of hurting themselves.
> >>>
> >>
> >> Please note that this is just on the bare command line. Libvirt and 
> >> friends will expand the model and have proper migration in place. What 
> >> exactly is your concern in that regard?
> > 
> > What is then the value? libvirt can also use host-model or  baselining if 
> > necessary.
> > And for the command line this will just add more opportunity to shot 
> > yourself in the
> > foot, no?
> 
> I don't think so. It's in no way more dangerous than "-cpu host" or
> "-cpu max". And it is in no way more dangerous than the discussed CPU
> versions, where even a "-cpu z13" would no longer be migration-safe.
> 
> You could - in theory - baseline(z13, host), but it could suddenly
> fallback to a, say, zEC12 - and that's not what you asked for. And you
> should not simply mask of deprecated features when baselining. Sure, we
> could eventually add config knobs for that , but ...
> 
> ... I really do like the part where you can specify on the command line
> to have specific CPU definition, but including all available/recommended
> features (e.g., nested virtualization).
> 
> > 
> > Let me put it this way, I might have misunderstood what you are trying to 
> > do here,
> > but if I do not get, then others (e.g. users) will also not get it.
> 
> I remember you participated in the relevant discussions. That's where we
> also agreed that versioned CPU models on s390x don't make any sense. But
> I can refine what's included in this patch description
> 
> "There is the demand from higher levels in the stack to "have the
> best CPU model possible on a given accelerator, firmware and HW"" - the
> best CPU model for a specific *CPU definition*.
> 
> Say the user has the option to select a model (zEC12, z13, z14), upper
> layers always want to have a model that includes all backported security
> features. While the host model can do that, CPU definitions can't. You
> can't change default models within a QEMU release, or for older releases
> (e.g., a z13).
> 

This is a good description of the main use case we're worried
about in x86 too, and the main reason we have added versioned CPU
models.

I remember I was planning to use `query-cpu-model-expansion` for
"please give me the best configuration for this specific CPU
model" (which would be very similar to the approach used in this
series).  Now, I need to refresh my memory and try to remember
why I concluded this approach wouldn't work for x86.


> > 
> > Maybe its just the interface or the name. But I find this very non-intuitive
> 
> I'm open for suggestions.
> 
> > 
> > e.g. you wrote
> > 
> >     Get the maximum possible feature set (e.g., including deprecated
> >     features) for a CPU definition in the configuration ("everything that
> >     could be enabled"):
> >         -cpu z14,all-features=off,available-features=on
> > 
> >     Get all valid features for a CPU definition:
> >         -cpu z14,all-features=on
> > 
> > What is the point of this? It is either the same as the one before, or it 
> > wont
> > be able to start. 
> 
> valid != available, all != available. Yes, the model won't run unless
> you are on pretty good HW :)
> 
> Maybe I should just have dropped the last example, as it seems to
> confuse people - it's mostly only relevant for introspection via CPU
> model expansion.
> 
> I am open for better names. e.g. all-features -> valid-features.

"all" is not a meaningful name to me.  It surely doesn't mean
"all features in the universe", so it means a more specific set
of features.  How is that set defined?

"valid" seems clearer, but we still need a description of what
"valid" means exactly.

-- 
Eduardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]