Re: [PATCH v8] qapi: introduce 'query-kvm-cpuid' action

[Philippe Mathieu-Daudé]

On 6/2/21 10:46 PM, Eduardo Habkost wrote:
> On Wed, Jun 02, 2021 at 08:17:28PM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Valeriy,
>>
>> (Sorry for not looking earlier than v8)
>>
>> On 5/31/21 2:38 PM, Valeriy Vdovin wrote:
>>> Introducing new qapi method 'query-kvm-cpuid'. This method can be used to
>>> get virtualized cpu model info generated by QEMU during VM initialization in
>>> the form of cpuid representation.
>>>
>>> Diving into more details about virtual cpu generation: QEMU first parses 
>>> '-cpu'
>>> command line option. From there it takes the name of the model as the basis 
>>> for
>>> feature set of the new virtual cpu. After that it uses trailing '-cpu' 
>>> options,
>>> that state if additional cpu features should be present on the virtual cpu 
>>> or
>>> excluded from it (tokens '+'/'-' or '=on'/'=off').
>>> After that QEMU checks if the host's cpu can actually support the derived
>>> feature set and applies host limitations to it.
>>> After this initialization procedure, virtual cpu has it's model and
>>> vendor names, and a working feature set and is ready for identification
>>> instructions such as CPUID.
>>>
>>> Currently full output for this method is only supported for x86 cpus.
>>>
>>> To learn exactly how virtual cpu is presented to the guest machine via CPUID
>>> instruction, new qapi method can be used. By calling 'query-kvm-cpuid'
>>> method, one can get a full listing of all CPUID leafs with subleafs which 
>>> are
>>> supported by the initialized virtual cpu.
>>>
>>> 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.
>>>
>>> Output format:
>>> The output is a plain list of leaf/subleaf agrument combinations, that
>>> return 4 words in registers EAX, EBX, ECX, EDX.
>>>
>>> Use example:
>>> qmp_request: {
>>>   "execute": "query-kvm-cpuid"
>>> }
>>>
>>> qmp_response: [
>>>   {
>>>     "eax": 1073741825,
>>>     "edx": 77,
>>>     "in_eax": 1073741824,
>>>     "ecx": 1447775574,
>>>     "ebx": 1263359563,
>>>   },
>>>   {
>>>     "eax": 16777339,
>>>     "edx": 0,
>>>     "in_eax": 1073741825,
>>>     "ecx": 0,
>>>     "ebx": 0,
>>>   },
>>>   {
>>>     "eax": 13,
>>>     "edx": 1231384169,
>>>     "in_eax": 0,
>>>     "ecx": 1818588270,
>>>     "ebx": 1970169159,
>>>   },
>>>   {
>>>     "eax": 198354,
>>>     "edx": 126614527,
>>>   ....
>>>
>>> Signed-off-by: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>

>>> +##
>>> +# @query-kvm-cpuid:
>>> +#
>>> +# Returns raw data from the KVM CPUID table for the first VCPU.
>>> +# The KVM CPUID table defines the response to the CPUID
>>> +# instruction when executed by the guest operating system.
>>
>> What is specific to KVM here?
>>
>> What about 'query-accel-cpuid' or 'query-vm-cpu-id'?
> 
> The implementation is KVM-specific.  I believe it's a reasonable
> compromise because the implementation is trivial, and a raw copy
> of the KVM CPUID table makes it a more useful (KVM-specific)
> debugging/testing mechanism.
> 
> I don't really mind how the command is called, but I would prefer
> to add a more complex abstraction only if maintainers of other
> accelerators are interested and volunteer to provide similar
> functionality.  I don't want to introduce complexity for use
> cases that may not even exist.

Fine, fair enough.