From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754884Ab1IHX12 (ORCPT ); Thu, 8 Sep 2011 19:27:28 -0400 Received: from claw.goop.org ([74.207.240.146]:55996 "EHLO claw.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752620Ab1IHX11 (ORCPT ); Thu, 8 Sep 2011 19:27:27 -0400 Message-ID: <4E68FB64.9080308@goop.org> Date: Thu, 08 Sep 2011 10:29:08 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Avi Kivity CC: Don Zickus , 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 Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking References: <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> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> <4E67C15B.3000408@goop.org> <4E6873FE.3040603@redhat.com> In-Reply-To: <4E6873FE.3040603@redhat.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/08/2011 12:51 AM, Avi Kivity wrote: > On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote: >> On 09/07/2011 10:41 AM, Avi Kivity wrote: >> >> Hm, I'm interested to know what you're thinking in more detail. >> Can you >> >> leave an NMI pending before you block in the same way you can with >> >> "sti;halt" with normal interrupts? >> > >> > >> > Nope. But you can do >> > >> > if (regs->rip in critical section) >> > regs->rip = after_halt; >> > >> > and effectively emulate it. The critical section is something like >> > >> > critical_section_start: >> > if (woken_up) >> > goto critical_section_end; >> > hlt >> > critical_section_end: >> >> Hm. It's a pity you have to deliver an actual interrupt to implement >> the kick though. > > I don't think it's that expensive, especially compared to the > double-context-switch and vmexit of the spinner going to sleep. On > AMD we do have to take an extra vmexit (on IRET) though. Fair enough - so if the vcpu blocks itself, it ends up being rescheduled in the NMI handler, which then returns to the lock slowpath. And if its a normal hlt, then you can also take interrupts if they're enabled while spinning. And if you get nested NMIs (since you can get multiple spurious kicks, or from other NMI sources), then one NMI will get latched and any others will get dropped? > Well we could have a specialized sleep/wakeup hypercall pair like Xen, > but I'd like to avoid it if at all possible. Yeah, that's something that just falls out of the existing event channel machinery, so it isn't something that I specifically added. But it does mean that you simply end up with a hypercall returning on kick, with no real complexities. J From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking Date: Thu, 08 Sep 2011 10:29:08 -0700 Message-ID: <4E68FB64.9080308@goop.org> References: <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> <4E679AF4.50209@redhat.com> <20110907165203.GQ6838@redhat.com> <4E67A551.4000502@redhat.com> <4E67A71A.5070903@goop.org> <4E67ACB6.40107@redhat.com> <4E67C15B.3000408@goop.org> <4E6873FE.3040603@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Don Zickus , Marcelo Tosatti , Nick Piggin , KVM , Stefano Stabellini , Peter Zijlstra , the arch/x86 maintainers , Linux Kernel Mailing List , Andi Kleen , Jeremy Fitzhardinge , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , Xen Devel To: Avi Kivity Return-path: In-Reply-To: <4E6873FE.3040603@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com List-Id: kvm.vger.kernel.org On 09/08/2011 12:51 AM, Avi Kivity wrote: > On 09/07/2011 10:09 PM, Jeremy Fitzhardinge wrote: >> On 09/07/2011 10:41 AM, Avi Kivity wrote: >> >> Hm, I'm interested to know what you're thinking in more detail. >> Can you >> >> leave an NMI pending before you block in the same way you can with >> >> "sti;halt" with normal interrupts? >> > >> > >> > Nope. But you can do >> > >> > if (regs->rip in critical section) >> > regs->rip = after_halt; >> > >> > and effectively emulate it. The critical section is something like >> > >> > critical_section_start: >> > if (woken_up) >> > goto critical_section_end; >> > hlt >> > critical_section_end: >> >> Hm. It's a pity you have to deliver an actual interrupt to implement >> the kick though. > > I don't think it's that expensive, especially compared to the > double-context-switch and vmexit of the spinner going to sleep. On > AMD we do have to take an extra vmexit (on IRET) though. Fair enough - so if the vcpu blocks itself, it ends up being rescheduled in the NMI handler, which then returns to the lock slowpath. And if its a normal hlt, then you can also take interrupts if they're enabled while spinning. And if you get nested NMIs (since you can get multiple spurious kicks, or from other NMI sources), then one NMI will get latched and any others will get dropped? > Well we could have a specialized sleep/wakeup hypercall pair like Xen, > but I'd like to avoid it if at all possible. Yeah, that's something that just falls out of the existing event channel machinery, so it isn't something that I specifically added. But it does mean that you simply end up with a hypercall returning on kick, with no real complexities. J