On Mon, 18 Nov 2019 at 22:04, Eduardo Habkost <ehabk...@redhat.com> 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... > 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. thanks -- PMM
