Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
On Wed, Mar 31, 2021 at 11:19:35AM +0200, Igor Mammedov wrote:
> On Tue, 30 Mar 2021 12:37:11 +0300
> Valeriy Vdovin wrote:
>
> > On Tue, Mar 30, 2021 at 02:15:10AM +0200, Igor Mammedov wrote:
> > > On Thu, 25 Mar 2021 19:57:05 +0300
> > > Valeriy Vdovin wrote:
> > >
> > > > Introducing new qapi method 'query-cpu-model-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-cpu-model-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.
> > >
> > >
> > > existing 'query-cpu-definitions' does return feature bits that are
> > > actually
> > > supported by qemu/host combination, why do we need a second very simillar
> > > interface?
> > >
> > We've examined 'query-cpu-definitions' as well as
> > 'query-cpu-model-expansion', which
> > is even a better fit for the job. But both methods just provide a list of
> > cpu features,
> > while leaving CPUID generation out of their scope.
> > Here is an example output from 'query-cpu-model-expansion':
> >
> > {
> > "return": {
> > "model": {
> > "name": "max",
> > "props": {
> >"vmx-entry-load-rtit-ctl": false,
> >"phys-bits": 0,
> >"core-id": -1,
> >"svme-addr-chk": false,
> >"xlevel": 2147483656,
> >"cmov": true,
> >"ia64": false,
> >"ssb-no": false,
> >"aes": false,
> >"vmx-apicv-xapic": true,
> >...
> >
> > However having this information we are only half-way there. We now need to
> > somehow
> > convert all this information into CPUID leaves, that we will be able to
> > give out
> > to the callers of 'cpuid' instruction. As we can see in the above listing,
> > the
> > field type is not even a uniform list of cpu features. It's an unordered
> > information
> > that matters for virtual cpu presentation each in it's own way.
>
> I'd say it returns flattened CPUID tree and also translated into feature
> names versus
> bits in CPUID leafs. But otherwise is serves the same purpose (to say what
> features
> resulting CPU model supports and what knobs one can use to tweak it).
> On top of that it's target agnostic.
>
Well, that is all true. As I've already mentioned it's not exactly the thing we
are
targeted to.
> > To construct CPUID leaves from that, the application should have ALL the
> > knowledge
> > about each type of the above properties list. This is the kind of code
> > writing that
> > we naturally want to evade knowing that there is a perfect function that
> > already does
> > that.
> It's typed JSON values, so json parser should do it for you (unless you parse
> output
> manually). The the same reasoning applies to raw CPUID data, it's a set
> words, where
> some words are bits showing which features are supported and some encode
> numeric or
> string values.
The problem is not in parsing value types in JSON. I was talking about the
non-uniformity
of the output data itself. In the example above '"xlevel": 2147483656' and
'"cmov": true"'
go side by side in the the same list, while the processing of both field would
be different.
"cmov": true - means bit 15 in EDX is set for leaf 01h, while "xlevel" :
2147483656 means
that maximum level for leaves starting from 0x8000 the cpu can output is
0x8008,
which is a completely different class of information. One needs to know what an
'xlevel' is
and how
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
On Tue, 30 Mar 2021 12:37:11 +0300
Valeriy Vdovin wrote:
> On Tue, Mar 30, 2021 at 02:15:10AM +0200, Igor Mammedov wrote:
> > On Thu, 25 Mar 2021 19:57:05 +0300
> > Valeriy Vdovin wrote:
> >
> > > Introducing new qapi method 'query-cpu-model-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-cpu-model-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.
> >
> >
> > existing 'query-cpu-definitions' does return feature bits that are actually
> > supported by qemu/host combination, why do we need a second very simillar
> > interface?
> >
> We've examined 'query-cpu-definitions' as well as
> 'query-cpu-model-expansion', which
> is even a better fit for the job. But both methods just provide a list of cpu
> features,
> while leaving CPUID generation out of their scope.
> Here is an example output from 'query-cpu-model-expansion':
>
> {
> "return": {
> "model": {
> "name": "max",
> "props": {
>"vmx-entry-load-rtit-ctl": false,
>"phys-bits": 0,
>"core-id": -1,
>"svme-addr-chk": false,
>"xlevel": 2147483656,
>"cmov": true,
>"ia64": false,
>"ssb-no": false,
>"aes": false,
>"vmx-apicv-xapic": true,
>...
>
> However having this information we are only half-way there. We now need to
> somehow
> convert all this information into CPUID leaves, that we will be able to give
> out
> to the callers of 'cpuid' instruction. As we can see in the above listing, the
> field type is not even a uniform list of cpu features. It's an unordered
> information
> that matters for virtual cpu presentation each in it's own way.
I'd say it returns flattened CPUID tree and also translated into feature names
versus
bits in CPUID leafs. But otherwise is serves the same purpose (to say what
features
resulting CPU model supports and what knobs one can use to tweak it).
On top of that it's target agnostic.
> To construct CPUID leaves from that, the application should have ALL the
> knowledge
> about each type of the above properties list. This is the kind of code
> writing that
> we naturally want to evade knowing that there is a perfect function that
> already does
> that.
It's typed JSON values, so json parser should do it for you (unless you parse
output
manually). The the same reasoning applies to raw CPUID data, it's a set words,
where
some words are bits showing which features are supported and some encode
numeric or
string values.
User of query-cpu-model-cpuid will have to parse that into separate
features to do something with it and have to translate into QEMU's features if
user decides to use this info enabling/disabling some features.
While 'query-cpu-model-expansion' has already done that from the very beginning.
So far need for introducing target specific query is not clear especially when
QEMU already provide the same data in a generic way.
The only clearly mentioned case in commit message is debugging, for that I'd add
tracing points at realize time (when QEMU does features 'expansion') instead of
extending external QAPI API.
It just seems to me that that described use-case doesn't warrant a redundant API
and it's unclear what user needs raw CPUID data for and why it can't reuse
'query-cpu-model-expansion', which should be sufficient for management purposes.
> I'm talking about 'cpu_x86_cpuid' in QEMU sources. It already does the whole
> CPUID
>
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
On Tue, Mar 30, 2021 at 02:15:10AM +0200, Igor Mammedov wrote:
> On Thu, 25 Mar 2021 19:57:05 +0300
> Valeriy Vdovin wrote:
>
> > Introducing new qapi method 'query-cpu-model-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-cpu-model-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.
>
>
> existing 'query-cpu-definitions' does return feature bits that are actually
> supported by qemu/host combination, why do we need a second very simillar
> interface?
>
We've examined 'query-cpu-definitions' as well as 'query-cpu-model-expansion',
which
is even a better fit for the job. But both methods just provide a list of cpu
features,
while leaving CPUID generation out of their scope.
Here is an example output from 'query-cpu-model-expansion':
{
"return": {
"model": {
"name": "max",
"props": {
"vmx-entry-load-rtit-ctl": false,
"phys-bits": 0,
"core-id": -1,
"svme-addr-chk": false,
"xlevel": 2147483656,
"cmov": true,
"ia64": false,
"ssb-no": false,
"aes": false,
"vmx-apicv-xapic": true,
...
However having this information we are only half-way there. We now need to
somehow
convert all this information into CPUID leaves, that we will be able to give
out
to the callers of 'cpuid' instruction. As we can see in the above listing, the
field type is not even a uniform list of cpu features. It's an unordered
information
that matters for virtual cpu presentation each in it's own way.
To construct CPUID leaves from that, the application should have ALL the
knowledge
about each type of the above properties list. This is the kind of code writing
that
we naturally want to evade knowing that there is a perfect function that
already does
that.
I'm talking about 'cpu_x86_cpuid' in QEMU sources. It already does the whole
CPUID
response construction. Just looking at its listing the function seems to be
pretty
complex. So writing the same logic will repeat the same complexity and all
risks.
Also it's in a public domain, so it's guaranteed to be revisisted, improved and
bug-fixed often.
So utilizing this function is an easy choice, in fact almost no choice. All we
need
is an api, that can fetch results from this function, which is exactly what our
new
QMP method does. The method is pretty straightforward, so there will be not
much to
maintain, compared to the effort that would need to be done to support future
CPU
features.
> >
> > Output format:
> > The core part of the returned JSON object can be described as a list of
> > lists
> > with top level list contains leaf-level elements and the bottom level
> > containing subleafs, where 'leaf' is CPUID argument passed in EAX register
> > and
> > 'subleaf' is a value passed to CPUID in ECX register for some specific
> > leafs, that support that. Each most basic CPUID result is passed in a
> > maximum of 4 registers EAX, EBX, ECX and EDX, with most leafs not utilizing
> > all 4 registers at once.
> > Also note that 'subleaf' is a kind of extension, used by only a couple of
> > leafs, while most of the leafs don't have this. Nevertheless, the output
> > data structure presents ALL leafs as having at least a single 'subleaf'.
> > This is done for data structure uniformity, so that it could be
> > processed in a more straightforward manner, in this case no one suffers
> > from such simplification.
> >
> > Use example:
> > virsh qemu-monitor-command VM --pretty '{ "execute":
> > "query-cpu-model-cpuid" }'
> >
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
On Thu, 25 Mar 2021 19:57:05 +0300
Valeriy Vdovin wrote:
> Introducing new qapi method 'query-cpu-model-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-cpu-model-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.
existing 'query-cpu-definitions' does return feature bits that are actually
supported by qemu/host combination, why do we need a second very simillar
interface?
>
> Output format:
> The core part of the returned JSON object can be described as a list of lists
> with top level list contains leaf-level elements and the bottom level
> containing subleafs, where 'leaf' is CPUID argument passed in EAX register and
> 'subleaf' is a value passed to CPUID in ECX register for some specific
> leafs, that support that. Each most basic CPUID result is passed in a
> maximum of 4 registers EAX, EBX, ECX and EDX, with most leafs not utilizing
> all 4 registers at once.
> Also note that 'subleaf' is a kind of extension, used by only a couple of
> leafs, while most of the leafs don't have this. Nevertheless, the output
> data structure presents ALL leafs as having at least a single 'subleaf'.
> This is done for data structure uniformity, so that it could be
> processed in a more straightforward manner, in this case no one suffers
> from such simplification.
>
> Use example:
> 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"
> }
>
> Signed-off-by: Valeriy Vdovin
> ---
> v2: - Removed leaf/subleaf iterators.
> - Modified cpu_x86_cpuid to return false in cases when count is
> greater than supported subleaves.
>
> qapi/machine-target.json | 122 +++
> target/i386/cpu.h| 2 +-
> target/i386/cpu.c| 209 +++
> 3 files changed, 315 insertions(+), 18 deletions(-)
>
> diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> index e7811654b7..c5b137aa5c 100644
> --- a/qapi/machine-target.json
> +++ b/qapi/machine-target.json
> @@ -329,3 +329,125 @@
> ##
> { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
>'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386)
> || defined(TARGET_S390X) || defined(TARGET_MIPS)' }
> +##
> +
> +
> +# @CpuidSubleaf:
> +#
> +# CPUID leaf extension information, based on ECX value.
> +#
> +# CPUID x86 instruction has 'leaf' argument passed in EAX register. Leaf
> +# argument identifies the type of information, the caller wants to retrieve
> in
> +# single call to
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
26.03.2021 18:18, Valeriy Vdovin wrote:
Also, we have implementation of qmp_query_cpu_* commands in different
architectures.. Probably we'll need add some stubs for the new command as well.
Currently I do not have a clear idea of how we could do this, because cpuid is
very specific to x86. Other cpu architectures also have cpu
identification means that could be close to x86 cpuid, but not as close to
easily generalize this method. But I'm willing to hear out a
good advice on this topic.
I mean, that I'm afraid, that after your patch QEMU will not compile for other
architectures, as it will say "no such qmp_query_model_cpuid function".
Probably I'm wrong. If I'm right, we'll need a stub implementation for other
architectures, like
qmp_query_model_cpuid(Error **errp)
{
error_setg(errp, "Not implemented");
}
--
Best regards,
Vladimir
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
On Fri, Mar 26, 2021 at 01:01:49PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 25.03.2021 19:57, Valeriy Vdovin wrote:
> >Introducing new qapi method 'query-cpu-model-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-cpu-model-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 core part of the returned JSON object can be described as a list of lists
> >with top level list contains leaf-level elements and the bottom level
> >containing subleafs, where 'leaf' is CPUID argument passed in EAX register
> >and
> >'subleaf' is a value passed to CPUID in ECX register for some specific
> >leafs, that support that. Each most basic CPUID result is passed in a
> >maximum of 4 registers EAX, EBX, ECX and EDX, with most leafs not utilizing
> >all 4 registers at once.
> >Also note that 'subleaf' is a kind of extension, used by only a couple of
> >leafs, while most of the leafs don't have this. Nevertheless, the output
> >data structure presents ALL leafs as having at least a single 'subleaf'.
> >This is done for data structure uniformity, so that it could be
> >processed in a more straightforward manner, in this case no one suffers
> >from such simplification.
> >
> >Use example:
> >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"
> >}
> >
> >Signed-off-by: Valeriy Vdovin
> >---
> >v2: - Removed leaf/subleaf iterators.
> > - Modified cpu_x86_cpuid to return false in cases when count is
> > greater than supported subleaves.
> >
> > qapi/machine-target.json | 122 +++
> > target/i386/cpu.h| 2 +-
> > target/i386/cpu.c| 209 +++
> > 3 files changed, 315 insertions(+), 18 deletions(-)
> >
> >diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> >index e7811654b7..c5b137aa5c 100644
> >--- a/qapi/machine-target.json
> >+++ b/qapi/machine-target.json
> >@@ -329,3 +329,125 @@
> > ##
> > { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
> >'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) ||
> > defined(TARGET_I386) || defined(TARGET_S390X) || defined(TARGET_MIPS)' }
> >+##
> >+
> >+
> >+# @CpuidSubleaf:
> >+#
> >+# CPUID leaf extension information, based on ECX value.
> >+#
> >+# CPUID x86 instruction has 'leaf' argument passed in EAX register. Leaf
> >+# argument
Re: [PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
25.03.2021 19:57, Valeriy Vdovin wrote:
Introducing new qapi method 'query-cpu-model-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-cpu-model-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 core part of the returned JSON object can be described as a list of lists
with top level list contains leaf-level elements and the bottom level
containing subleafs, where 'leaf' is CPUID argument passed in EAX register and
'subleaf' is a value passed to CPUID in ECX register for some specific
leafs, that support that. Each most basic CPUID result is passed in a
maximum of 4 registers EAX, EBX, ECX and EDX, with most leafs not utilizing
all 4 registers at once.
Also note that 'subleaf' is a kind of extension, used by only a couple of
leafs, while most of the leafs don't have this. Nevertheless, the output
data structure presents ALL leafs as having at least a single 'subleaf'.
This is done for data structure uniformity, so that it could be
processed in a more straightforward manner, in this case no one suffers
from such simplification.
Use example:
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"
}
Signed-off-by: Valeriy Vdovin
---
v2: - Removed leaf/subleaf iterators.
- Modified cpu_x86_cpuid to return false in cases when count is
greater than supported subleaves.
qapi/machine-target.json | 122 +++
target/i386/cpu.h| 2 +-
target/i386/cpu.c| 209 +++
3 files changed, 315 insertions(+), 18 deletions(-)
diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index e7811654b7..c5b137aa5c 100644
--- a/qapi/machine-target.json
+++ b/qapi/machine-target.json
@@ -329,3 +329,125 @@
##
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386)
|| defined(TARGET_S390X) || defined(TARGET_MIPS)' }
+##
+
+
+# @CpuidSubleaf:
+#
+# CPUID leaf extension information, based on ECX value.
+#
+# CPUID x86 instruction has 'leaf' argument passed in EAX register. Leaf
+# argument identifies the type of information, the caller wants to retrieve in
+# single call to CPUID.
+# Some but not all leaves depend on the value passed in ECX register as an
+# additional argument to CPUID. This argument is present in cpuid documentation
+# as 'subleaf'.
+# If CPUID ignores the value in ECX, normally this means that leaf does not
+# have subleaves. Another way to see it is that each leaf has at least one
+# subleaf (one type of output).
+#
+# @subleaf: value passed
[PATCH v2] qapi: introduce 'query-cpu-model-cpuid' action
Introducing new qapi method 'query-cpu-model-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-cpu-model-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 core part of the returned JSON object can be described as a list of lists
with top level list contains leaf-level elements and the bottom level
containing subleafs, where 'leaf' is CPUID argument passed in EAX register and
'subleaf' is a value passed to CPUID in ECX register for some specific
leafs, that support that. Each most basic CPUID result is passed in a
maximum of 4 registers EAX, EBX, ECX and EDX, with most leafs not utilizing
all 4 registers at once.
Also note that 'subleaf' is a kind of extension, used by only a couple of
leafs, while most of the leafs don't have this. Nevertheless, the output
data structure presents ALL leafs as having at least a single 'subleaf'.
This is done for data structure uniformity, so that it could be
processed in a more straightforward manner, in this case no one suffers
from such simplification.
Use example:
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"
}
Signed-off-by: Valeriy Vdovin
---
v2: - Removed leaf/subleaf iterators.
- Modified cpu_x86_cpuid to return false in cases when count is
greater than supported subleaves.
qapi/machine-target.json | 122 +++
target/i386/cpu.h| 2 +-
target/i386/cpu.c| 209 +++
3 files changed, 315 insertions(+), 18 deletions(-)
diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index e7811654b7..c5b137aa5c 100644
--- a/qapi/machine-target.json
+++ b/qapi/machine-target.json
@@ -329,3 +329,125 @@
##
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
'if': 'defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_I386) ||
defined(TARGET_S390X) || defined(TARGET_MIPS)' }
+##
+
+
+# @CpuidSubleaf:
+#
+# CPUID leaf extension information, based on ECX value.
+#
+# CPUID x86 instruction has 'leaf' argument passed in EAX register. Leaf
+# argument identifies the type of information, the caller wants to retrieve in
+# single call to CPUID.
+# Some but not all leaves depend on the value passed in ECX register as an
+# additional argument to CPUID. This argument is present in cpuid documentation
+# as 'subleaf'.
+# If CPUID ignores the value in ECX, normally this means that leaf does not
+# have subleaves. Another way to see it is that each leaf has at least one
+# subleaf (one type of output).
+#
+# @subleaf: value passed to CPUID in ECX register. If CPUID leaf has only a
+# single leaf, the value of ECX is
