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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

> From: Teddy Astie
> Sent: Monday, July 27, 2026 12:48 PM
> To: Stephen Cheng （程小枫）; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Ross Lagerwall; Andrew Cooper; Anthony PERARD; Michal Orzel; Jan Beulich; 
> Julien Grall; Roger Pau Monné; Stefano Stabellini; Jason Andryuk
> Subject: Re: [PATCH] x86/svm: require VMSAVEvirt for nested virt
> 
> 
> 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.
> 

Given the limited resources we have to try to make nested virt functional and
eventually production ready, I think any time spent making it work on older
processors and then testing it is a waste. AMD nested virt doesn't work now so
removing support for older processors is not a regression in functionality.

Ross