Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 2/2] KVM: VMX: Invoke NMI handler via indirect call instead of INTn
Date:   Mon, 26 Apr 2021 08:09:46 -0700
Message-Id: <E67D7461-68B3-44E5-ADB5-52E5A4D3897D@amacapital.net>
References: <20210426145104.GW1401198@tassilo.jf.intel.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Lai Jiangshan <jiangshanlai+lkml@gmail.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Uros Bizjak <ubizjak@gmail.com>,
        Andy Lutomirski <luto@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>
In-Reply-To: <20210426145104.GW1401198@tassilo.jf.intel.com>
To:     Andi Kleen <ak@linux.intel.com>
Precedence: bulk


> On Apr 26, 2021, at 7:51 AM, Andi Kleen <ak@linux.intel.com> wrote:
>=20
> =EF=BB=BF
>>=20
>>> The original code "int $2" can provide the needed CPU-hidden-NMI-masked
>>> when entering #NMI, but I doubt it about this change.
>>=20
>> How would "int $2" block NMIs?  The hidden effect of this change (and I
>> should have reviewed better the effect on the NMI entry code) is that the=

>> call will not use the IST anymore.
>=20
> My understanding is that int $2 does not block NMIs.
>=20
> So reentries might have been possible.
>=20

The C NMI code has its own reentrancy protection and has for years.  It shou=
ld work fine for this use case.

> -Andi