WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 08/13] xen/pvticketlock: disable interrupts while blocking
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Sun, 11 Sep 2011 12:59:36 +0300
Cc: Don Zickus <dzickus@xxxxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, KVM <kvm@xxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Andi Kleen <andi@xxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 11 Sep 2011 03:01:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E68FB64.9080308@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1314996468.8255.0.camel@twins> <4E614FBD.2030509@xxxxxxxx> <20110906151408.GA7459@xxxxxxxxxx> <4E66615E.8070806@xxxxxxxx> <20110906182758.GR5795@xxxxxxxxxx> <4E66EF86.9070200@xxxxxxxxxx> <20110907134411.GV5795@xxxxxxxxxx> <4E678992.5050709@xxxxxxxxxx> <20110907155657.GX5795@xxxxxxxxxx> <4E679AF4.50209@xxxxxxxxxx> <20110907165203.GQ6838@xxxxxxxxxx> <4E67A551.4000502@xxxxxxxxxx> <4E67A71A.5070903@xxxxxxxx> <4E67ACB6.40107@xxxxxxxxxx> <4E67C15B.3000408@xxxxxxxx> <4E6873FE.3040603@xxxxxxxxxx> <4E68FB64.9080308@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0
On 09/08/2011 08:29 PM, Jeremy Fitzhardinge wrote:
>  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.

Yes. To be clear, just execute 'hlt' and inherit the interrupt enable flag from the environment.

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?

While we're in the NMI handler, any further NMIs will be collapsed and queued (so one NMI can be in service and just one other queued behind it). We can detect this condition by checking %rip on stack.


>  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.

It also has to return on interrupt, MNI, INIT etc. "No real complexities" is a meaningless phrase on x86, though it is fertile ground for math puns.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>