From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH v2] KVM: x86: Inject pending interrupt even if pending nmi exist Date: Wed, 23 Mar 2016 22:00:59 +0100 Message-ID: <56F3040B.8070006@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> 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: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:33498 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834AbcCWVBE (ORCPT ); Wed, 23 Mar 2016 17:01:04 -0400 Received: by mail-wm0-f67.google.com with SMTP id u125so7307362wmg.0 for ; Wed, 23 Mar 2016 14:01:03 -0700 (PDT) In-Reply-To: <20160323190406.GB22164@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 nothin= g), > so reasons behind "supposed to" elude me. http://www.spinics.net/lists/kvm/msg61313.html provides the relevant history lesson: 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 cause two NMI events in the CPU? Then this is required." 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, and if we detect a back-to-back NMI, handle all possible NMI sources." Not sure if that change actually ever happened in Linux (Avi went on describing an application to pvspinlocks, but pvspinlocks ended up _not= _ using NMIs), actually. The Intel SDM is very obscure, AMD a bit less. It says: "The processor recognizes an NMI at an instruction boundary. [...] NMI cannot be masked. However, when an NMI is recognized by the processor, recognitio= n of subsequent NMIs are disabled until an IRET instruction is executed." Here recognition means delivery, acceptance need not be at instruction boundaries (it can be at clock cycle boundary). It might be possible t= o figure this out on bare-metal by executing an expensive instruction suc= h as MFENCE. 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 is the special NMI shadow from the STI instruction. Paolo