From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org,
Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>,
Denis Lunev <den@openvz.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v8] qapi: introduce 'query-kvm-cpuid' action
Date: Thu, 3 Jun 2021 01:24:02 +0200 [thread overview]
Message-ID: <4e53e323-076c-da89-4239-cb15df8de210@redhat.com> (raw)
In-Reply-To: <20210602204604.crsxvqixkkll4ef4@habkost.net>
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.
next prev parent reply other threads:[~2021-06-02 23:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-31 12:38 [PATCH v8] qapi: introduce 'query-kvm-cpuid' action Valeriy Vdovin
2021-06-02 12:24 ` Vladimir Sementsov-Ogievskiy
2021-06-02 18:17 ` Philippe Mathieu-Daudé
2021-06-02 20:46 ` Eduardo Habkost
2021-06-02 23:24 ` Philippe Mathieu-Daudé [this message]
2021-06-02 20:51 ` Eric Blake
2021-06-02 21:01 ` Eduardo Habkost
2021-06-03 8:21 ` Valeriy Vdovin
2021-06-08 15:14 ` Markus Armbruster
2021-06-08 15:27 ` Valeriy Vdovin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e53e323-076c-da89-4239-cb15df8de210@redhat.com \
--to=philmd@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=valeriy.vdovin@virtuozzo.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).