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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/05/2026 8:53 am, Jan Beulich wrote:
> On 14.05.2026 19:56, Andrew Cooper wrote:
>> --- a/xen/arch/x86/hvm/svm/intr.c
>> +++ b/xen/arch/x86/hvm/svm/intr.c
>> @@ -33,6 +33,12 @@ static void svm_inject_nmi(struct vcpu *v)
>>      u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>>      intinfo_t event;
>>  
>> +    if ( vmcb->_vintr.fields.vnmi_enable )
>> +    {
>> +        vmcb->_vintr.fields.vnmi_pending = true;
>> +        return;
>> +    }
> How does all of this work during migration to a vNMI-incapable host? The
> hw feature is used ...
>
>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>> @@ -185,6 +185,8 @@ static int construct_vmcb(struct vcpu *v)
>>      if ( default_xen_spec_ctrl == SPEC_CTRL_STIBP )
>>          v->arch.msrs->spec_ctrl.raw = SPEC_CTRL_STIBP;
>>  
>> +    vmcb->_vintr.fields.vnmi_enable = cpu_has_svm_vnmi;
> ... unconditionally when available (i.e. the feature not being there
> won't prevent the migration), yet the vnmi_{pend,block}ing fields are
> lost during migration (aiui). Are building on the fact that all of this
> state is already getting lost while migrating?

I can't quite parse the final sentence, but yes; migration has always
lost the NMI state.

This goes largely unnoticed because guests don't issue their final
suspend from NMI context.

~Andrew