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

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

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 <stephen.cheng@xxxxxxxxxx>
> ---
>   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

Attachment: OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature