From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andi Kleen" Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking Date: Sat, 3 Sep 2011 01:14:55 +0200 Message-ID: References: <38bb37e15f6e5056d5238adac945bc1837a996ec.1314922370.git.jeremy.fitzhardinge@citrix.com> <1314974826.1861.1.camel@twins> <4E612EA1.20007@goop.org> <1314996468.8255.0.camel@twins> <4E614FBD.2030509@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: In-Reply-To: <4E614FBD.2030509@goop.org> Sender: kvm-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: Peter Zijlstra , "H. Peter Anvin" , Linus Torvalds , Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List , Nick Piggin , Avi Kivity , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Jeremy Fitzhardinge , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org > But, erm, does that even make sense? I'm assuming the NMI reason port > tells the CPU why it got an NMI. If multiple CPUs can get NMIs and > there's only a single reason port, then doesn't that mean that either 1) > they all got the NMI for the same reason, or 2) having a single port is > inherently racy? How does the locking actually work there? All the code to determine NMI reasons is inherently racy, and each new NMI user makes it worse. -Andi