Re: [PATCH v2] x86/nSVM: Save L2's CR0, CR4 and EFER on #VMEXIT, not Xen's

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.09.2026 12:23, Lin Liu wrote:
> nsvm_vmcb_prepare4vmexit() copies CR0, CR4 and EFER out of the shadow
> VMCB, but Xen does not run L2 with L2's own values: svm_update_guest_cr()
> ORs in HVM_CR4_HOST_MASK and, under shadow paging, CR0.PG|WP, and
> svm_update_guest_efer() forces EFER.SVME.  Hardware writes back what L2
> ran with, so L1 reads Xen's bits back as L2's.  Save the shadowed values
> instead.
> 
> CR4 leaks CR4.MCE under HAP.  EFER is observable on a VMRUN rejected for
> SVME=0: L1 gets back a VMCB with the bit it deliberately cleared.  CR0 is
> a no-op today, since nested virt requires HAP, and is changed for
> consistency.
> 
> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization")
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Lin Liu <lin.liu01@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

However, ...

> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -1079,11 +1079,11 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
> cpu_user_regs *regs)
>      ns_vmcb->_cpl = n2vmcb->_cpl;
>  
>      /* EFER */
> -    ns_vmcb->_efer = n2vmcb->_efer;
> +    ns_vmcb->_efer = v->arch.hvm.guest_efer;
>  
>      /* CRn */
> -    ns_vmcb->_cr4 = n2vmcb->_cr4;
> -    ns_vmcb->_cr0 = n2vmcb->_cr0;
> +    ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4];
> +    ns_vmcb->_cr0 = v->arch.hvm.guest_cr[0];
>  
>      /* DRn */
>      ns_vmcb->_dr7 = n2vmcb->_dr7;

... I still think it is a mistake to leave alone the similar CR2 handling
code further down in the function. Yes, #PF handling in
nsvm_vcpu_vmexit_inject() updates the value, but as indicated before that
(aiui) still leaves (at least) the case where L2 writes CR2 explicitly.

nestedsvm_vmexit_n2n1() -> nsvm_vmcb_prepare4vmexit() runs ahead of
nsvm_vcpu_vmexit_inject(), i.e. whatever nsvm_vmcb_prepare4vmexit() would
store would still be properly updated by nsvm_vcpu_vmexit_inject() (yet,
as said, only in the #PF case).

Jan