Re: [PATCH for-4.22 v6] x86/svm: Support vNMI on capable hardware

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/05/2026 10:20 am, Teddy Astie wrote:
> Le 14/05/2026 à 19:59, Andrew Cooper a écrit :
>> From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@xxxxxxxxxx>
>>
>> Starting with Zen4, AMD CPUs can virtualise NMIs for a guest.  On older
>> hardware, determining when an NMI is safe to deliver is a challenge
>> and Xen
>> does not handle all corner cases correctly.
>>
>> With vNMI, there is an enablement bit and two new bits of state in
>> the VMCB; a
>> pending bit, and a blocked bit.  These directly map to the CPU state for
>> handling NMIs, and are maintained by hardware during the running of
>> the vCPU.
>>
>> When vNMI is enabled, have svm_{get,set}set_interrupt_shadow() work
>> in terms
>> of the vnmi_blocking bit rather than the IRET intercept.  This allows an
>> emulated IRET instruction to re-enable NMIs.
>>
>> When injecting a new NMI, simply set the vnmi_pending bit; hardware will
>> deliver the NMI to the guest at the next suitable juncture.
>>
>> One complication is that, when delivering a second NMI before the
>> first has
>> completed, the mix between common HVM logic and SVM specific logic
>> will try to
>> open an NMI window, malfunctioning as it does so.  When vNMI is
>> enabled, short
>> circuit this to not consider NMIs blocked.
>>
>> Signed-off-by: Abdelkareem Abdelsaamad
>> <abdelkareem.abdelsaamad@xxxxxxxxxx>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> CC: Teddy Astie <teddy.astie@xxxxxxxxxx>
>> CC: Jason Andryuk <jason.andryuk@xxxxxxx>
>> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>
>> For 4.22.  This is somewhat overdue and makes a concrete improvement
>> to NMI
>> handling on recent AMD hardware.
>>
>> v6:
>>   * Plumb through svm_{get,set}set_interrupt_shadow() so that
>> emulated IRET
>>     works, as requested several times during review of earlier
>> revisions.
>>   * Expand the commit message
>>
>> The !vNMI case is even more broken than I'd realised.  Besides the
>> "what if
>> the IRET faults?" problem, svm_enable_intr_window() basically ignores
>> the NMI
>> case and simply re-enters the VM.  This causes the pending NMI to
>> only be
>> injected next time there is a VMExit.
>
> Does that happens often in practice ?

Which?

VMs don't tend to make as much use of NMIs as native does.

IRET faulting is mostly relegated to misbehaving userspace.  E.g. one
thread uses SYSCALL_modify_ldt to invalidate the %ss/%cs that another
thread was running on, at which point the next reload of that segment
(generally the next IRET) will fault.  But to attack this, userspace
needs to hit the IRET of the NMI handler with this race, and avoid the
IRET of all other interrupts and exceptions.  Perf counters is the
typically the only way userspace has to influence this, and we don't
have PMU available to guests by default.

Then we get into differences between Intel and AMD.  Intel unblocks NMIs
even if the IRET faults.  AMD unblocks NMIs only in the IRET completes.

With Xen's current SVM code and without vNMI, IRETs get Intel-like
behaviour WRT faulting, and already pending NMIs get delayed.  Software
needs to cope with the former, and the latter (while far from ideal) is
generally indistinguishable from the NMI being slightly later than it
was in practice.

 
> Reviewed-by: Teddy Astie <teddy.astie@xxxxxxxxxx>

Thanks.

~Andrew