[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: |
Mon, 18 Nov 2019 15:49:06 -0300 |
On Mon, Nov 18, 2019 at 11:56:43AM +0100, David Hildenbrand wrote:
> On 18.11.19 11:53, Peter Maydell wrote:
> > On Mon, 18 Nov 2019 at 10:47, David Hildenbrand <address@hidden> wrote:
> > > My personal opinion: "max" really means "all features". If we want an
> > > automatic way to specify something you requested ("give me something
> > > that's going to work") we either have to change the definition of the
> > > max model for alla rchitectures or introduce something that really
> > > matches the "no -cpu specified" - e.g., "best".
> >
> > I don't strongly object to 'max' including deprecated features,
> > but I do definitely object to 'max' including by default any
> > experimental (x- prefix) features. Those should never be
> > enabled (whatever the '-cpu foo' name) unless the user has
> > specifically opted into them: that's the point of the x- prefix.
> > We need to be able to tell from the command line whether it's
> > got any non-standard weirdness enabled.
>
> I'll let Eduardo respond to that, as we don't really have experimental
> features on s390x, especially under KVM ("host" corresponds to "max").
Be them experimental or deprecated, we need all features included
on "max" if we want to make them usable through libvirt. The
fact Peter cares about defaults in "max" when used by humans
indicates we have incompatible definitions of "max", and I don't
think we can conciliate them.
We could rename the CPU model that is intended for humans on arm,
or we can document clearly that the semantics of "max" in
x86/s390x are completely different from arm. Peter, what do you
prefer?
--
Eduardo
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, (continued)
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/08
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/08
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/08
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Eduardo Habkost, 2019/11/08
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/08
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/09
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants,
Eduardo Habkost <=
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Eduardo Habkost, 2019/11/18
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/19
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/19
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Peter Maydell, 2019/11/19
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/19
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Eduardo Habkost, 2019/11/19
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/20
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, Eduardo Habkost, 2019/11/20
- Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants, David Hildenbrand, 2019/11/20