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

[Valeriy Vdovin]

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).

> > 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.
> 
> 
> 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 :|
>