From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist Date: Wed, 23 Mar 2016 22:06:36 +0100 Message-ID: <56F3055C.8090004@siemens.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" , Nobuo Yoshida To: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from thoth.sbs.de ([192.35.17.2]:43779 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750886AbcCWVGr (ORCPT ); Wed, 23 Mar 2016 17:06:47 -0400 In-Reply-To: <56F3040B.8070006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2016-03-23 22:00, Paolo Bonzini wrote: >=20 >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 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. This sounds to me like we should try to address the issue Yuki is seein= g without playing with the nmi_pending counter. Jan --=20 Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux