У вт, 2023-10-10 у 07:46 -0700, Sean Christopherson пише:
> On Tue, Oct 10, 2023, Maxim Levitsky wrote:
> > У пн, 2023-10-09 у 14:29 -0700, Sean Christopherson пише:
> > > Note, per the APM, hardware sets the BLOCKING flag when software directly
> > > directly injects an NMI:
> > >
> > > If Event Injection is used to inject an NMI when NMI Virtualization is
> > > enabled, VMRUN sets V_NMI_MASK in the guest state.
> >
> > I think that this comment is not needed in the commit message. It describes
> > a different unrelated concern and can be put somewhere in the code but
> > not in the commit message.
>
> I strongly disagree, this blurb in the APM directly affects the patch. If hardware
> didn't set V_NMI_MASK, then the patch would need to be at least this:
I don't see how 'the blurb in the APM' relates to the removal of the
IRET intercept, which is what this patch is about.
If the hardware was not to set the V_NMI_BLOCKING_MASK during EVENTINJ NMI injection,
we would have had a bigger problem, a problem which would have to be addressed
before this patch, because kvm reads back the V_NMI_BLOCKING_MASK
(see: svm_get_nmi_mask()) to check if NMI is blocked, something that
has no relation to the IRET interception.
Best regards,
Maxim Levtsky
>
> --
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index b7472ad183b9..d34ee3b8293e 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3569,8 +3569,12 @@ static void svm_inject_nmi(struct kvm_vcpu *vcpu)
> if (svm->nmi_l1_to_l2)
> return;
>
> - svm->nmi_masked = true;
> - svm_set_iret_intercept(svm);
> + if (is_vnmi_enabled(svm)) {
> + svm->vmcb->control.int_ctl |= V_NMI_BLOCKING_MASK;
> + } else {
> + svm->nmi_masked = true;
> + svm_set_iret_intercept(svm);
> + }
> ++vcpu->stat.nmi_injections;
> }
>
>
> base-commit: 86701e115030e020a052216baa942e8547e0b487
