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