[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: David Hildenbrand
Subject: Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Date: Tue, 19 Nov 2019 10:58:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

On 19.11.19 10:22, Peter Maydell wrote:
On Mon, 18 Nov 2019 at 22:04, Eduardo Habkost <address@hidden> wrote:

On Mon, Nov 18, 2019 at 09:19:55PM +0000, Peter Maydell wrote:
Why should it matter whether a feature is enabled
or disabled by default in the CPU type? It ought to be probeable
by QMP either way (ie there is a difference between
"this CPU has this feature switch and it is on by default",
"this CPU has this feature switch and it is off by default"
and "this CPU does not have this feature switch at all",
and presumably libvirt needs to distinguish them).

Its use case is neither "this CPU has this feature switch" or for
"it is on|off by default".  We use it to probe for "this feature
can be enabled in this host hardware+kernel+QEMU combination".

OK. Well, the answer to that depends on the name of the CPU,
in general. So you can't use a fake CPU name to try to answer
the question.

In other words, in x86 and s390x "max" is just a reserved name
for the query-cpu-model-expansion command arguments in s390x and
x86.  The fact that it is visible to users can be considered a
bug, and we can fix that.

I think 'max' is useful to users, and we've provided it to users,
so removing it again would be a compatibility break. I'm not
entirely sure where we go from here...

I agree, right now on s390x "-cpu max" behaves almost like "-cpu qemu"/"-cpu host", but you don't have to care about the accelerator. Removing it might we evil. Removing it is not really an option.

If you still don't like how query-cpu-model-expansion works, we
can also discuss that.  But I'm not sure it would be a good use
of our (and libvirt developers') time.

I don't hugely care about query-cpu-model-expansion. I
just don't want it to have bad effects on the semantics
of user-facing stuff like x- properties.

IMHO, max should really include all features (yes, also the bad x-features on arm :) ) and we should have a way to give users the opportunity to specify "just give me the best model independent of the accelerator" - something like a "best" model, but I don't care about the name.

E.g., we could introduce a new model for that purpose and start warning if "-cpu max" is used (and recommend them to use the other model) to run a VM and not simply to query model properties via the qmp interfaces. The users are aware of the model restrictions and can switch.



David / dhildenb

reply via email to

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