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(a)suse.com&gt; > --- > > 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.