From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking Date: Wed, 07 Sep 2011 19:25:24 +0300 Message-ID: <4E679AF4.50209@redhat.com> References: <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> <20110906151408.GA7459@redhat.com> <4E66615E.8070806@goop.org> <20110906182758.GR5795@redhat.com> <4E66EF86.9070200@redhat.com> <20110907134411.GV5795@redhat.com> <4E678992.5050709@redhat.com> <20110907155657.GX5795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110907155657.GX5795@redhat.com> Sender: kvm-owner@vger.kernel.org To: Don Zickus Cc: Jeremy Fitzhardinge , Peter Zijlstra , "H. Peter Anvin" , Linus Torvalds , Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List , Nick Piggin , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Jeremy Fitzhardinge , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 09/07/2011 06:56 PM, Don Zickus wrote: > > > > And hope that no other NMI was generated while we're handling this > > one. It's a little... fragile? > > No. If another NMI is generated while we are processing the current one > it should get latched. Upon completion of the current one, the cpu should > jump right back into the nmi exception routine again. The only downside > is when multiple NMIs come in during the processing of the current one. > Only one can be latched, so the others get dropped. Ah, yes, I remember now. > But we are addressing > that. > May I ask how? Detecting a back-to-back NMI? -- error compiling committee.c: too many arguments to function