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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/10/2026 5:54 pm, Ross Lagerwall wrote:
>> 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.

This comes back to policy work.

Luckily for AMD it's easy, because the information is in CPUID.  There's
a series of mine from a while back doing this which needs committing.

~Andrew