qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>
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>
Subject: Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Date: Mon, 18 Nov 2019 11:47:30 +0100	[thread overview]
Message-ID: <66c64c6d-b7c0-2cb1-2b29-4fdd9b369714@redhat.com> (raw)
In-Reply-To: <CAFEAcA_No5oAFtULbAOrPDeQE18HHgc0agXbs4m2AGZ+gK_ReQ@mail.gmail.com>

On 09.11.19 17:07, Peter Maydell wrote:
> On Fri, 8 Nov 2019 at 19:11, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>
>> On Fri, Nov 08, 2019 at 01:02:28PM +0000, Peter Maydell wrote:
>>> On Fri, 8 Nov 2019 at 12:46, David Hildenbrand <david@redhat.com> 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".
> 
> How does "host" work for TCG on x86?

I think just like on s390x, host is limited to KVM only.

> 
>>> 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.
> 
> We seem to have a disagreement here about what 'max' is intended
> for and what its semantics for. That seems unfortunate...
> 
> For Arm, "max" is absolutely something we want to expose to
> end users. It's the easiest way for a user to say "give me
> something that's going to work". "host" doesn't work on TCG,
> only with KVM.

t460s: ~/git/qemu master $ s390x-softmmu/qemu-system-s390x -cpu help | 
grep max
s390 max             Enables all features supported by the accelerator 
in the current host

t460s: ~/git/qemu master $ x86_64-softmmu/qemu-system-x86_64 -cpu help | 
grep max
x86 max                   Enables all features supported by the 
accelerator in the current host

x86 and s390x interpret the "all features supported" as "possible in 
this configuration", not "supported" like in a support statement.

When not passing a "-cpu", you will automatically get the default model 
assigned (e.g., host vs. qemu model on s390x). "max" does no mimic that!

> 
>>> '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".
> 
> No, definitely not. Experimental features should never be
> enabled by default -- the user must explicitly opt into them
> so they are aware that they're using something that might
> change behaviour or go away in a future QEMU version.
> 
> Also, from my point of view "max" is not for the benefit
> of management software in particular. It's a convenience
> for users primarily (and also for management software if
> it doesn't want to care whether it's running KVM or TCG).
> 
> If management software wants a way to ask "what features
> might be valid" we should provide them with one which
> doesn't require those features to be enabled-by-default
> in the 'max' CPU.
> 
> thanks
> -- PMM
> 

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

-- 

Thanks,

David / dhildenb



  reply	other threads:[~2019-11-18 10:49 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
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 [this message]
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=66c64c6d-b7c0-2cb1-2b29-4fdd9b369714@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).