Re: [PATCH] x86/svm: require VMSAVEvirt for nested virt

Teddy Astie <[email protected]> Mon, 27 Jul 2026 13:48:30 +0200

Newsgroups	org.xenproject.lists.xen-devel
Message-ID	<1785152912.8631fc262581453bbf619ec5b2062170.19fa367bc22000e099@vates.tech>

Le 27/07/2026 à 09:20, Stephen Cheng a écrit :
> Virtual VMLOAD/VMSAVE lets an L1 guest execute VMLOAD and VMSAVE
> without intercepts.  Without it, Xen has to map the L1-provided VMCB
> and re-execute each instruction in L0, complicating security-sensitive
> state handling.
> 
> Make VMSAVEvirt a hard requirement for nested SVM.  Advertise it to
> L1, enable it when L1 enables SVM, and remove the nested VMLOAD/VMSAVE
> emulation path.  Any remaining intercept therefore comes from a guest
> which has not enabled SVM and receives #UD.
> 
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Stephen Cheng <[email protected]>
> ---
>   docs/designs/nested-svm-cpu-features.md |  11 +++
>   xen/arch/x86/cpu-policy.c               |   3 +-
>   xen/arch/x86/hvm/svm/nestedsvm.c        |  24 ++++--
>   xen/arch/x86/hvm/svm/svm.c              | 100 +++---------------------
>   xen/arch/x86/hvm/svm/svm.h              |   2 -
>   5 files changed, 41 insertions(+), 99 deletions(-)
> 
> diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md
> index ce168e68e1..798480b259 100644
> --- a/docs/designs/nested-svm-cpu-features.md
> +++ b/docs/designs/nested-svm-cpu-features.md
> @@ -109,3 +109,14 @@ 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.
> +
> +- 15 `VLoadSave` *Virtual VMLOAD/VMSAVE*: Require for L0, provide to L1
> +
> +  Without this feature Xen has to intercept the L1 hypervisor's VMLOAD
> +  and VMSAVE instructions and emulate them by re-executing the real
> +  instruction on a mapped copy of the L1-supplied VMCB.  That path
> +  handles a complex, security-sensitive subset of state (the hidden
> +  segment descriptors for FS/GS/TR/LDTR plus the SYSCALL/SYSENTER
> +  MSRs), so on faithfulness grounds we'd much rather let the hardware
> +  do it.  When present, the instructions execute natively in the guest
> +  without a #VMEXIT, which is both simpler and faster.

I'm not convinced making "VMSAVEvirt" mandatory is a good idea, in 
particular, there is a errata (1454 - Processor May Log Unexpected LS 
MCE Error When Executing Virtualized VMLOAD or Virtualized VMSAVE) on 
Family 19h regarding this feature.

Had you considered improving the current implementation of virtualized 
VMLOAD/VMSAVE ? AIUI, the way Xen currently implements this instruction 
(by mapping the L1 VMCB then calling vmload/vmsave on it) is more of a 
implementation choice than a requirement.

A better (at least, likely safer) way to emulate such instructions (and 
not relying on VMSAVEvirt) would be to copy parts of L1 VMCB from/to L0 
VMCB and let Xen perform the appropriate vmload/vmsave on its own VMCBs 
as usual.

Teddy

OpenPGP_0x660FA9D102CBCFD0.asc (application/pgp-keys, 2.4 KB)

OpenPGP_signature.asc (application/pgp-signature, 665 B)