On Mon, Mar 23, 2020 at 15:47:49 -0600, Jim Fehlig wrote:
The domain capabilities documentation contains a small but confusing error in the host-model CPU description, referencing the element <mode> instead of <model>. Fix this small typo.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> ---
I only found this small typo (well, I'm pretty sure it's a typo :-)) by tring to understand a more confusing observation. On a machine where capabilities reports CascaseLake-Server, domcapabilities reports
<mode name='host-model' supported='yes'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='pku'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='invtsc'/> </mode> <mode name='custom' supported='yes'> ... <model usable='no'>Cascadelake-Server</model> </mode>
So using host-model will result in a CascadeLake-Server CPU, but it is not supported when specifying a custom CPU? Interestingly, I see something similar from domcapabilities on machine where capabilities reports Skylake-Server-IBRS
<mode name='host-model' supported='yes'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='invtsc'/> <feature policy='disable' name='pku'/> <feature policy='disable' name='avx512vnni'/> </mode> <mode name='custom' supported='yes'> ... <model usable='no'>Skylake-Server-IBRS</model> <model usable='no'>Skylake-Server</model> <model usable='no'>Cascadelake-Server</model> </mode>
This seems contradictory to me but perhaps I'm overlooking something?
The usable=yse|no attribute says whether a given CPU model can be provided to a guest without any modification. That is whether you can use <cpu mode='custom' match='exact'> <model fallback='forbid'>Cascadelake-Server</model> </cpu> When usable='no', QEMU will need to disable some of the features that are part of the Cascadelake-Server CPU model. In other words, the CPU model is not usable as is. On the other hand, the <mode name='host-model'> element in domain capabilities describes the CPU used as a host-model CPU by adding or removing some specific features. In other words, while using the simple CPU definition mentioned above would cause QEMU to drop some features, using a more verbose <cpu mode='custom' match='exact'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='xsaves'/> <feature policy='require' name='invtsc'/> <feature policy='disable' name='pku'/> <feature policy='disable' name='avx512vnni'/> </cpu> explicitly asks QEMU to disable pku and avx512vnni features and thus QEMU will not have to disable anything. The situation on the first machine is a bit strange as there are no features disabled in host-model CPU definition, which makes it unclear why QEMU reports Cascadelake-Server as unusable (QEMU reports the reason, but we don't do so yet). Anyway, would you mind running the tests/cputestdata/cpu-gather.sh script on both machines (make sure to install qemu, python3, and cpuid packages first) and send us the output so that we can check the CPU models are properly detected?
docs/formatdomaincaps.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index 66e758501b..7fd1f91f73 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -232,7 +232,7 @@ <dt><code>host-model</code></dt> <dd> If <code>host-model</code> is supported by the hypervisor, the - <code>mode</code> describes the guest CPU which will be used when + <code>model</code> describes the guest CPU which will be used when starting a domain with <code>host-model</code> CPU. The hypervisor specifics (such as unsupported CPU models or features, machine type, etc.) may be accounted for in this guest CPU specification and thus
As strange as it seems, there's no typo. The <model> element describes just a small part of the whole CPU. There are additional <vendor> and <feature> elements which also belong to the CPU definition. All these elements are children of the <mode> element and thus the <mode> element describes the guest CPU. Yes, this is not the best design and having an entire <cpu> element rather than its children in the <mode name='host-model' supported='yes'> element would be better, but we can't really do anything about it now. Jirka