From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist Date: Wed, 23 Mar 2016 22:52:12 +0100 Message-ID: <20160323215212.GB18007@potion.brq.redhat.com> References: <7CC7D3013F4B10479273CE019E6A8C7A3ED90C@BPXM15GP.gisp.nec.co.jp> <56F297A7.1030309@redhat.com> <20160323172159.GA22164@potion.brq.redhat.com> <56F2DEDD.5060600@redhat.com> <20160323190406.GB22164@potion.brq.redhat.com> <56F3040B.8070006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Yuki Shibuya , "kvm@vger.kernel.org" , Jan Kiszka , Nobuo Yoshida To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36748 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbcCWVwQ (ORCPT ); Wed, 23 Mar 2016 17:52:16 -0400 Content-Disposition: inline In-Reply-To: <56F3040B.8070006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-03-23 22:00+0100, Paolo Bonzini: > On 23/03/2016 20:04, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> I think that hardware coalesces all NMIs that arrive within one >> instruction (NMI is delivered at instruction boundaries) >> and one NMI is sufficient anyway (all events that triggered NMIs are >> going to be handled in the first one and the second one is for nothi= ng), >> so reasons behind "supposed to" elude me. >=20 > http://www.spinics.net/lists/kvm/msg61313.html provides the relevant > history lesson: Very nice, thanks! > Jan: "Thinking this through again, it's actually not yet clear to me > what we are modeling here: If two NMI events arrive almost perfectly = in > parallel, does the real hardware guarantee that they will always caus= e > two NMI events in the CPU? Then this is required." >=20 > Avi: "It's not 100% clear from the SDM, but this is what I understood > from it. And it's needed - the NMI handlers are now being reworked to > handle just one NMI source (hopefully the cheapest) in the handler, a= nd > if we detect a back-to-back NMI, handle all possible NMI sources." >=20 > Not sure if that change actually ever happened in Linux (Avi went on > describing an application to pvspinlocks, but pvspinlocks ended up _n= ot_ > using NMIs), actually. All NMI handlers are called now (nmi_handle) and it would be quite wron= g to do otherwise, because NMIs do collapse in both models. > The Intel SDM is very obscure, AMD a bit less. It says: "The process= or > recognizes an NMI at an instruction boundary. [...] NMI cannot be > masked. However, when an NMI is recognized by the processor, recognit= ion > of subsequent NMIs are disabled until an IRET instruction is executed= =2E" > Here recognition means delivery, acceptance need not be at instructio= n > boundaries (it can be at clock cycle boundary). It might be possible= to > figure this out on bare-metal by executing an expensive instruction s= uch > as MFENCE. Yes. :( > There is also at least one case where you could have one pending (but > not injected) and one latched NMI at instruction boundary, and that i= s > the special NMI shadow from the STI instruction. I think that STI will keep the NMI latched (pending is a synonym) and that there is nothing between injected (recognized) and latched. APM (vol2, 15.21.5 Interrupt Shadows) says that interrupts aren't recognized during shadow. And that "The saved instruction pointer points to the instruction immediately following the boundary where the NMI was recognized." (vol2, 8.2.3 NMI=E2=80=94Non-Maskable-Interrupt Ex= ception), so recognizing the NMI after STI would mean that we'd execute some instruction twice ...