[PATCH] docs: fix typo in domcaps host-model CPU description
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? 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 -- 2.25.0
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
On 3/24/20 3:44 AM, Jiri Denemark wrote:
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.
Thanks for the detailed explanation!
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).
It's not clear to me even after looking at the output of cpu-gather.
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?
Attached.
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.
Ah, yes, now it makes sense. Thanks again! Regards, Jim
On 3/24/20 8:30 AM, Jim Fehlig wrote:
On 3/24/20 3:44 AM, Jiri Denemark wrote:
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).
It's not clear to me even after looking at the output of cpu-gather.
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?
Attached.
While experimenting with some guests on the first machine (kernel 4.12.14, qemu 3.1.1, libvirt.git master) I encountered https://bugs.launchpad.net/intel/+bug/1828495 while trying to restore a guest whose CPU was set to host-model. The guest starts fine, although I do see qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] in the guest log file. Save works as expected but then restore fails with error: Failed to restore domain from /home/jim/sles12sp5-kvm.save error: operation failed: guest CPU doesn't match specification: missing features: ospke I wouldn't be surprised if my kernel and qemu are missing some commits mentioned in the LP bug (there are a lot of them!), but shouldn't it be possible to restore the guest if libvirt previously started it successfully? Regards, Jim
On 3/24/20 3:44 AM, Jiri Denemark wrote:
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).
I got back to looking at this again today and found my older qemu is missing some patches. Sorry for wasting time, but thanks for helping me understand this topic a bit better! Regards, Jim
participants (2)
-
Jim Fehlig -
Jiri Denemark