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