Re: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested #VMEXIT

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.10.2026 09:06, chunjie.zhu@xxxxxxxxxx wrote:
> From: Chunjie Zhu <chunjie.zhu@xxxxxxxxxx>
> 
> When V_NMI_ENABLE is set, the processor manages V_NMI and V_NMI_MASK
> automatically (including on IRET), and writes both back to the VMCB on
> VMEXIT (APM vol.2 rev 3.44, "NMI Virtualization").
> 
> nsvm_vmcb_prepare4vmexit() only propagated V_TPR, V_IRQ and (conditionally)
> V_GIF from the L2 shadow VMCB into vmcb12. V_NMI and V_NMI_MASK were never
> copied back, so L1 kept seeing whatever it had last written, regardless of
> what happened in L2.
> 
> Copy both back when L1 has enabled vNMI for its guest.
> 
> Fixes: 86a203ab8d38 ("x86/svm: Support vNMI on capable hardware")
> Signed-off-by: Chunjie Zhu <chunjie.zhu@xxxxxxxxxx>

I was meaning to apply this, but ...

> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -1027,12 +1027,19 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
> cpu_user_regs *regs)
>      /*
>       * Virtual Interrupts.  #VMEXIT writes back V_TPR and V_IRQ (APM vol.2
>       * 15.6); the remaining fields do not change.  Copy vGIF back only if
> -     * enabled in L1.
> +     * enabled in L1.  With vNMI enabled, the processor manages V_NMI and
> +     * V_NMI_MASK itself and writes both back on #VMEXIT (APM vol.2 rev 3.44,
> +     * "NMI Virtualization").
>       */
>      ns_vmcb->_vintr.fields.tpr = n2vmcb->_vintr.fields.tpr;
>      ns_vmcb->_vintr.fields.irq = n2vmcb->_vintr.fields.irq;
>      if ( ns_vmcb->_vintr.fields.vgif_enable )
>          ns_vmcb->_vintr.fields.vgif = n2vmcb->_vintr.fields.vgif;
> +    if ( ns_vmcb->_vintr.fields.vnmi_enable )
> +    {
> +        ns_vmcb->_vintr.fields.vnmi_pending = 
> n2vmcb->_vintr.fields.vnmi_pending;
> +        ns_vmcb->_vintr.fields.vnmi_blocking = 
> n2vmcb->_vintr.fields.vnmi_blocking;
> +    }
>  
>      /* Interrupt state */
>      ns_vmcb->int_stat = n2vmcb->int_stat;

... except for the bottom patch context, the code being altered doesn't
exist in staging at all. It also didn't change recently, so I wonder
what code base you took this from.

Jan