Re: [PATCH v1] x86/nestedsvm: Require SpecCtrl

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Le 20/10/2026 à 07:01, chunjie.zhu@xxxxxxxxxx a écrit :
> From: Chunjie Zhu <chunjie.zhu@xxxxxxxxxx>
>
> Previously L0 did not expose this bit, forcing L1 to intercept and
> emulate MSR_SPEC_CTRL accesses from L2 in software, which is
> functionally correct but suboptimal. Per APM vol.2 rev 3.44 "SPEC_CTRL
> Virtualization", hardware supports combining host and guest SPEC_CTRL
> values via VMCB.spec_ctrl with a logical OR while a guest runs, and
> saves the (possibly guest-modified) value back into VMCB.spec_ctrl
> on #VMEXIT.
>
> Require the SVM SpecCtrl feature before running any nested virt
> guests.
>
> Update docs/designs/nested-svm-cpu-features.md with the rationale
> for requiring and exposing bit 20 (SpecCtrl).
>
> Signed-off-by: Chunjie Zhu <chunjie.zhu@xxxxxxxxxx>
> ---
>   docs/designs/nested-svm-cpu-features.md | 13 +++++++++++++
>   xen/arch/x86/cpu-policy.c               |  3 ++-
>   xen/arch/x86/hvm/svm/nestedsvm.c        | 26 ++++++++++++++++++++++++-
>   3 files changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/docs/designs/nested-svm-cpu-features.md 
> b/docs/designs/nested-svm-cpu-features.md
> index ce168e68e1b3..6999fcf1bb72 100644
> --- a/docs/designs/nested-svm-cpu-features.md
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -109,3 +109,16 @@ leaf 8000000A:edx
>     Using it in L0 reduces the chance that we'll make some sort of error
>     in the decode path.  And if hardware supports it, it's easy enough
>     to provide to the L1.
> +
> +- 20 `SpecCtrl` *MSR_SPEC_CTRL virtualisation*: Require for L0, provide to L1
> +
> +  L0 already relies on this feature to virtualize MSR_SPEC_CTRL for the
> +  L1 hypervisor itself (see `X86_FEATURE_SC_MSR_HVM`).  Requiring it
> +  as a baseline for nested virt (first available on Zen2) means L1 can
> +  rely on the same hardware virtualisation for its own L2 guests,
> +  instead of having L0 unconditionally intercept and trap/emulate
> +  MSR_SPEC_CTRL accesses coming from L2.  Providing it to L1 is
> +  basically free once it's required of L0, and it removes a
> +  significant amount of "CPU without the feature" fallback code that
> +  would otherwise need to be implemented and maintained for nested
> +  virt.
I'm not sure we actually need this requirement.

A comment regarding MSR_SPEC_CTRL virtualization suggest that 
MSR_SPEC_CTRL virtualization is as old as MSR_SPEC_CTRL itself
> Virtualising MSR_SPEC_CTRL for guests depends on SVM support, which
> on real hardware matches the availability of MSR_SPEC_CTRL in the
> first place.

So if there's no MSR_SPEC_CTRL, there is nothing special to do for 
nested virt.
What we can eventually say is that we can require MSR_SPEC_CTRL 
virtualization support iff we want host MSR_SPEC_CTRL.
Teddy

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature