[Top][All Lists]

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

Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants

From: Eduardo Habkost
Subject: Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Date: Fri, 8 Nov 2019 16:10:57 -0300

On Fri, Nov 08, 2019 at 01:02:28PM +0000, Peter Maydell wrote:
> On Fri, 8 Nov 2019 at 12:46, David Hildenbrand <address@hidden> wrote:
> > There is a small but important difference between "max"/"host" and
> > "best". Max really means "all features", including deprecated ones.
> > "best", however, can disable experimental or deprecated features. Or any
> > other features we don't want to be enabled when somebody selects a model
> > manually.

On x86, this is implemented by "host".  "max" gives you the full
set of features that can be enabled by the user.  "host" gives
you a reasonable set of features you will want to see enabled by
default when the user says "use the host CPU".

> >
> > On s390x, the feature "csske" is deprecated. New HW still has it, but we
> > want new guests to run without this facility. Dropping it from "max"
> > would affect existing setups. We already changed the default model
> > (e.g., -cpu z13) to disable it with never QEMU machines.
> >
> > E.g., nested virtualization features on some architectures could be a
> > feature set you want to disable, although contained in the "max" model.
> > (e.g., no migration support yet).
> >
> >
> > I am not completely against calling these "max" models instead of "best"
> > models, but I think this makes it clearer that there is indeed a difference.
> Hmm. I see the distinction, but is it one that's sufficiently
> worth making that we want to expose it to our users, possibly
> try to add it to the other architectures, etc ? How bad is it
> if the CPU provides some legacy deprecated feature that the
> guest just doesn't use ?

"max" isn't something we want to expose to end users.  It is
something we need to expose to other software components.

> 'max' already shouldn't include experimental features, at least
> for Arm -- those should be off by default, because they're
> experimental and you only want users to get them if they
> explicitly opt in via '-cpu something,+x-my-feature'.

The whole point of "max" is to tell management software which
features are valid to be enabled in a host.  If "+x-my-feature"
works, "x-my-feature" must be included in "max".


reply via email to

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