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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> on behalf of 
> chunjie.zhu@xxxxxxxxxx <chunjie.zhu@xxxxxxxxxx>
> Sent: Friday, October 16, 2026 08:06
> To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx 
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: Chunjie Zhu （朱春杰） <chunjie.zhu@xxxxxxxxxx>; jason.andryuk@xxxxxxx 
> <jason.andryuk@xxxxxxx>; jbeulich@xxxxxxxx <jbeulich@xxxxxxxx>; 
> roger@xxxxxxxxxxxxxx <roger@xxxxxxxxxxxxxx>; teddy.astie@xxxxxxxxxx 
> <teddy.astie@xxxxxxxxxx>
> Subject: [PATCH v2] x86/nestedsvm: write back V_NMI and V_NMI_MASK on nested 
> #VMEXIT
>
>
> 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>
> ---
> v2:
>  * Reword commit message: the processor manages V_NMI/V_NMI_MASK itself.
>  * Add Fixes: tag.
>  * Cite APM by revision and section title.
> ---
>  xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c 
> b/xen/arch/x86/hvm/svm/nestedsvm.c
> index faacfe007832..3a0afa98129e 100644
> --- 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;
> --
> 2.34.1

The issue here is that Xen allows L1 to enable VNMI in the first place
while it hasn't exposed the feature to L1.  This is because Xen blindly
copies the entire vintr field (except V_INTR_MASKING) from VMCB(1-2),
which incidentally also allows the guest to enable AVIC and unexpectedly
get AVIC-related VMEXITs as reported here:
https://lore.kernel.org/xen-devel/CA+aCS-Ha4jSYFfxhOwMGiGJPdCOtgBJLt=3Q=v9dfp6SQJys4w@xxxxxxxxxxxxxx/T/#u

First, we need to fix that bug by copying only the relevant supported
parts of vintr from VMCB(1-2).

Then, as a separate series, expose the VNMI feature bit to the VM (if
supported by hardware) and make it work correctly.

Ross