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

[Daniel P . Berrangé]

On Mon, Mar 29, 2021 at 02:21:53PM +0300, Valeriy Vdovin wrote:
> On Mon, Mar 29, 2021 at 10:20:54AM +0100, Daniel P. Berrang?? wrote:
> > On Fri, Mar 26, 2021 at 08:30:00PM +0300, Valeriy Vdovin wrote:
> > > Other than debug, the method is useful in cases when we would like to
> > > utilize QEMU's virtual cpu initialization routines and put the retrieved
> > > values into kernel CPUID overriding mechanics for more precise control
> > > over how various processes perceive its underlying hardware with
> > > container processes as a good example.
> > 
> > When I read this, my impression is that QEMU's CPU handling doesn't do
> > what you need, and you're trying to work around it outside of QEMU.
> > Can you give more detailed information about what situations QEMU's
> > CPUID handling doesn't work, and why we can't simply enhance QEMU
> > to do what you need ?
> > 
> We want to override CPUID for container processes to support live
> migration. For that we want to base on a reliable cpu model, which is
> present in libvirt and QEMU. We will communicate cpu models information
> between physical nodes to decide the baseline cpu model and then we could
> use the new method to get all CPUID value leaves that we would return to
> containers during CPUID override. In our case the QAPI-way of getting the
> values is a clean solution, because we can just query it from the outside
> (not as guest system).

IIUC, you seem to be saying that you're not actually going to run a
real QEMU VM at all ?  You're just using QEMU / QMP as a convenient
way expand a named CPI model into CPUID leaves, so you can then use
this data in a completely separate container based mgmt application.
Essentially treating QMP as a general purpose API for handling CPU
models.

> > > virsh qemu-monitor-command VM --pretty '{ "execute": 
> > > "query-cpu-model-cpuid" }'
> > > {
> > >   "return": {
> > >     "cpuid": {
> > >       "leafs": [
> > >         {
> > >           "leaf": 0,
> > >           "subleafs": [
> > >             {
> > >               "eax": 13,
> > >               "edx": 1231384169,
> > >               "ecx": 1818588270,
> > >               "ebx": 1970169159,
> > >               "subleaf": 0
> > >             }
> > >           ]
> > >         },
> > >         {
> > >           "leaf": 1,
> > >           "subleafs": [
> > >             {
> > >               "eax": 329443,
> > >               "edx": 529267711,
> > >               "ecx": 4160369187,
> > >               "ebx": 133120,
> > >               "subleaf": 0
> > >             }
> > >           ]
> > >         },
> > >         {
> > >           "leaf": 2,
> > >           "subleafs": [
> > >             {
> > >               "eax": 1,
> > >               "edx": 2895997,
> > >               "ecx": 0,
> > >               "ebx": 0,
> > >               "subleaf": 0
> > >             }
> > >           ]
> > >         },
> > >       ]
> > >     },
> > >     "vendor": "GenuineIntel",
> > >     "class-name": "Skylake-Client-IBRS-x86_64-cpu",
> > >     "model-id": "Intel Core Processor (Skylake, IBRS)"
> > >   },
> > >   "id": "libvirt-40"
> > > }
> > 
> > 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|