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

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 18 Nov 2019 at 18:49, Eduardo Habkost <ehabkost@redhat.com> wrote:
> 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?

I don't want us to have different definitions of max on different
architectures if we can avoid it. More importantly, I don't think that
x- features should ever be enabled by default for *any* CPU type
on *any* architecture (unless the CPU type itself was experimental,
I suppose), whatever that architecture's semantics for 'max',
'best', etc are.

I think the solution to this is to not use 'max' as some odd way of
letting libvirt do feature detection. I'm not sure how trying to
use 'max' as a proxy for "all features on" would work for features
which can't exist on 'max' but do exist on other CPU types
(for instance for Arm some features make no sense on the
A-profile 'max' CPU and aren't provided there, but do exist for
M-profile CPUs like cortex-m4), so I don't see how libvirt
can usefully use it anyway.

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

thanks
-- PMM