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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.05.2026 13:12, Andrew Cooper wrote:
> 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.

In which case:
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan

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