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

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>,
	"Eduardo Habkost" <ehabkost@redhat.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>,
	"Janosch Frank" <frankja@linux.ibm.com>
Subject: Re: [PATCH v1 0/2] s390x/cpumodel: Introduce "best" model variants
Date: Tue, 19 Nov 2019 12:00:14 +0100	[thread overview]
Message-ID: <1fd9876d-5ad9-15e9-a2dc-6e5e747f9ca8@redhat.com> (raw)
In-Reply-To: <CAFEAcA-egL5kbo81eBT+FVBz7vSaWqUVzFUF3MNOttnzY6vZMQ@mail.gmail.com>

On 19.11.19 11:36, Peter Maydell wrote:
> On Tue, 19 Nov 2019 at 09:59, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 19.11.19 10:22, Peter Maydell wrote:
>>> 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.
> 
> How would "max includes all features" work if we have two
> x- features (or even two normal features!) which are incompatible
> with each other? How does it work for features which are

I assume the "max" model should at least be consistent, see below.

> valid for some other CPU type but not for 'max'? The design
> seems to assume a rather simplified system where every
> feature is independent and can always be applied to every
> CPU, which I don't think is guaranteed to be the case.

I do agree that the use case of "max" for detecting which features can 
be enabled for any CPU model is quite simplified and would also not work 
like this on s390x. It really means "give me the maximum/latest/greatest 
you can". Some examples on s390x:

On s390x, we don't allow to enable new features for older CPU 
generation. "vx" was introduced with a z13. If "max" is a z13, it can 
include "vx", if available. However, if you select a z12 (zEC12), you 
cannot enable "vx":

"Feature '%s' is not available for CPU model '%s', it was introduced 
with later models."

Also, we have dependency checks 
(target/s390x/cpu_models.c:check_consistency()), that at least warn on 
inconsistencies between features (feature X requires feature Y).

We would need more fine-grained "max" models. E.g., z13-max vs. z13-best 
vs. z13-base.

- z13-max: Maximum features that can be enabled on the current
            accel/host for a z13.
- z13-best: Best features that can be enabled on the current
            accel/host for a z13.
- z13-base: base feature set, independent of current
            accel/host for a z13. (we do have this already on s390x)

> 
> thanks
> -- PMM
> 

-- 

Thanks,

David / dhildenb