qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	"Michael Mueller" <mimu@linux.ibm.com>,
	"Jiri Denemark" <jdenemar@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Date: Fri, 8 Nov 2019 13:46:01 +0100	[thread overview]
Message-ID: <5dd613c0-6d9e-b943-b64d-7ba1791cbefe@redhat.com> (raw)
In-Reply-To: <CAFEAcA-mD3-Zg2JunGpMqbcaT1qboCenhqEFytZD0FmFcL2i9Q@mail.gmail.com>

On 08.11.19 12:10, Peter Maydell wrote:
> On Fri, 8 Nov 2019 at 11:08, David Hildenbrand <david@redhat.com> wrote:
>>
>> There was recently a discussion regarding CPU model versions. That concept
>> does not fit s390x where we have a lot of feature variability. I
>> proposed an alternative approach in [1], which might work for x86 as well
>> (but I am not sure if x86 still can or wants to switch to that), and
>> requires no real changes in upper layers.
>>
>> [1] and patch #2 contains more information on the motivation for this.
>>
>> E.g., specifying/expanding "z14-best" will result in the "best feature
>> set possible on this accelerator, hw and, firmware". While a "z13" does
>> not work under TCG and some z/VM versions, "z13-best" will work.
> 
> I think other architectures call this concept "max", not "best".
> If we can manage some cross-architecture consistency that would
> be helpful, but is s390x using 'max' already for something else?

We have the "max" model just like other architectures

s390 max             Enables all features supported by the accelerator 
in the current host

It is basically the "host" model under KVM, and the "qemu" model under 
TCG (with minor differences for the latter).


This series introduces e.g.,

s390 z900-best       IBM zSeries 900 GA1 with best features supported by 
the accelerator in the current host

s390 z14-best        IBM z14 GA1 with best features supported by the 
accelerator in the current host

s390 z14ZR1-best     IBM z14 Model ZR1 GA1 with best features supported 
by the accelerator in the current host

s390 gen15a-best     IBM z15 GA1 with best features supported by the 
accelerator in the current host

s390 gen15b-best     IBM 8562 GA1 with best features supported by the 
accelerator in the current host


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 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.

Maybe, we even want a "-cpu best" that would not map to "-cpu 
host"/"-cpu max", but to a cleaned up "-cpu host"/"-cpu max" (e.g., 
disable deprecated features). Long term, we might even want to change 
the default when no "-cpu" is specified to "-cpu best" - which should 
now be possible with the latest QEMU changes to query the default model 
for a specific QEMU machine.

-- 

Thanks,

David / dhildenb



  reply	other threads:[~2019-11-08 12:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 11:07 [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants David Hildenbrand
2019-11-08 11:07 ` [PATCH v1 1/2] s390x/cpumodels: Factor out CPU feature dependencies David Hildenbrand
2019-11-08 11:07 ` [PATCH v1 2/2] s390x/cpumodel: Introduce "best" model variants David Hildenbrand
2019-11-08 19:51   ` Eduardo Habkost
2019-11-08 21:18     ` David Hildenbrand
2019-11-08 11:10 ` [PATCH v1 0/2] " Peter Maydell
2019-11-08 12:46   ` David Hildenbrand [this message]
2019-11-08 13:02     ` Peter Maydell
2019-11-08 19:10       ` Eduardo Habkost
2019-11-08 22:58         ` David Hildenbrand
2019-11-09 16:07         ` Peter Maydell
2019-11-18 10:47           ` David Hildenbrand
2019-11-18 10:53             ` Peter Maydell
2019-11-18 10:56               ` David Hildenbrand
2019-11-18 10:59                 ` Peter Maydell
2019-11-18 18:49                 ` Eduardo Habkost
2019-11-18 21:19                   ` Peter Maydell
2019-11-18 22:04                     ` Eduardo Habkost
2019-11-19  9:22                       ` Peter Maydell
2019-11-19  9:58                         ` David Hildenbrand
2019-11-19 10:36                           ` Peter Maydell
2019-11-19 11:00                             ` David Hildenbrand
2019-11-19 19:42                               ` Eduardo Habkost
2019-11-20 10:28                                 ` David Hildenbrand
2019-11-20 14:04                                   ` Eduardo Habkost
2019-11-20 14:21                                     ` David Hildenbrand
2019-11-08 16:59 ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5dd613c0-6d9e-b943-b64d-7ba1791cbefe@redhat.com \
    --to=david@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=jdenemar@redhat.com \
    --cc=mimu@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).