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

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

29.03.2021 14:48, Daniel P. Berrangé wrote:
> 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.
> 

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?

-- 
Best regards,
Vladimir