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

[Eduardo Habkost]

On Mon, Nov 18, 2019 at 09:19:55PM +0000, Peter Maydell wrote:
> On Mon, 18 Nov 2019 at 18:49, Eduardo Habkost <address@hidden> 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.

libvirt uses it through query-cpu-model-expansion.

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

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.

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.

-- 
Eduardo