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"
}
Also, cpu_x86_cpuid function has been modified to return bool
value depending on what are the arguments of leaf and subleaf
(or index and count). In cases where leaf/subleaf arguments are
invalid the function returns false.
Signed-off-by: Valeriy Vdovin<valeriy.vdovin@virtuozzo.com>