Re: [PATCH v3] qapi: introduce 'query-cpu-model-cpuid' action

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Mar 29, 2021 at 03:41:34PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 29.03.2021 14:48, Daniel P. Berrangé wrote:
[...]
> > > > There's feels like there's a lot of conceptual overlap with the
> > > > query-cpu-model-expansion command. That reports in a arch independant
> > > > format, but IIUC the property data it returns can be mapped into
> > > > CPUID leaf values. Is it not possible for you to use this existing
> > > > command and maintain a mapping of property names -> CPUID leaves ?
> > > As already stated in the use-case description above, having this method
> > > around, helps us in a way that we can just take values and return them
> > > to containers. QEMU code already does a great job, generating CPUID
> > > responses, we don't want to do the same in our own code.
> > 
> > This is asking QEMU to maintain a new QAPI command which does not appear
> > to have a use case / benefit for QEMU mgmt. It isn't clear to me that
> > this should be considered in scope for QMP.
> > 
> 
> Hmm. On the other hand,
> 
> 1. The command just exports some information, like a lot of other qmp query- commands, it doesn't look as something alien in the QEMU interface.
> 
> 2. We do have a use-case. Not a VM use-case, but a use-case of cpu handling subsystem.
> 
> Isn't it enough?
> 
> We want to handle cpu configurations in a compatible with QEMU way. The simplest thing for it is just generate needed information with help of QEMU. Note, that's not the only usage of QEMU binary for not-VM-running. QEMU binary may be used for different block-jobs and manipulating bitmaps in disk images (yes, now we also have qemu-storage-daemon, but still).
> 
> Do you have an idea how our task could be solved an a better way?

The new command would also be useful for writing automated tests
for the x86 CPUID compatibility code.  I don't object to its
inclusion.

-- 
Eduardo