| 
         
xen-devel
[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravi
 
| 
To:  | 
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> | 
 
| 
Subject:  | 
[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable | 
 
| 
From:  | 
Zachary Amsden <zach@xxxxxxxxxx> | 
 
| 
Date:  | 
Tue, 20 Mar 2007 18:53:54 -0800 | 
 
| 
Cc:  | 
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx,	akpm@xxxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx,	netdev@xxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>,	linux-kernel@xxxxxxxxxxxxxxx, chrisw@xxxxxxxxxxxx, Andi Kleen <ak@xxxxxx>,	"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>,	anthony@xxxxxxxxxxxxx, mingo@xxxxxxx, David Miller <davem@xxxxxxxxxxxxx> | 
 
| 
Delivery-date:  | 
Tue, 20 Mar 2007 18:52:28 -0700 | 
 
| 
Envelope-to:  | 
www-data@xxxxxxxxxxxxxxxxxx | 
 
| 
In-reply-to:  | 
<Pine.LNX.4.64.0703201715470.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx> | 
 
| 
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/cgi-bin/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe> | 
 
| 
List-unsubscribe:  | 
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> | 
 
| 
References:  | 
<20070316.023331.59468179.davem@xxxxxxxxxxxxx>	<45FB005D.9060809@xxxxxxxx>	<1174127638.8897.75.camel@xxxxxxxxxxxxxxxxxxxxx>	<20070318.003309.71088169.davem@xxxxxxxxxxxxx>	<20070318120814.GA45869@xxxxxx>	<1174272469.11680.23.camel@xxxxxxxxxxxxxxxxxxxxx>	<m1648xxf93.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx>	<Pine.LNX.4.64.0703191134190.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>	<1174348905.11680.54.camel@xxxxxxxxxxxxxxxxxxxxx>	<45FF4043.4000805@xxxxxxxxxx> <45FF770C.7050301@xxxxxxxx>	<Pine.LNX.4.64.0703200805450.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>	<m1mz27sy82.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx>	<Pine.LNX.4.64.0703200903500.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>	<46000C7E.4070001@xxxxxxxx> <46005B89.5070301@xxxxxxxxxx>	<Pine.LNX.4.64.0703201715470.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx> | 
 
| 
Sender:  | 
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx | 
 
| 
User-agent:  | 
Thunderbird 1.5.0.10 (X11/20070221) | 
 
 
 
Linus Torvalds wrote:
 
On Tue, 20 Mar 2007, Zachary Amsden wrote:
   
void local_irq_restore(int enabled)
{
   pda.intr_mask = enabled;
   /*
    * note there is a window here where softirqs are not processed by
    * the interrupt handler, but that is not a problem, since it will
    * get done here in the outer enable of any nested pair.
    */
   if (enabled)
       local_bh_enable();
}
    
 
 Actually, this one is more complicated. You also need to actually enable 
hardware interrupts again if they got disabled by an interrupt actually 
occurring while the "soft-interrupt" was disabled.
  
 
 Actually, I was thinking the irq handlers would just not mess around 
with eflags on the stack, just call the chip to ack the interrupt and 
re-enable hardware interrupts when they left, since that is free anyway 
with the iret.  Maybe leaving irqs disabled is better.
 Anyway, it really *should* be pretty damn simple. No need to disable 
preemption, there should be no events that can *cause* it, since all 
interrupts get headed off at the pass.. (the return-from-interrupt thng 
should already notice that it's returning to an interrupts-disabled 
section and not try to do any preemption).
  
What did I miss?
  
 
 I wasn't disabling preemption to actually disable preemption.  I was 
just using bh_disable as a global hammer to stop softirqs (thus the irq 
replay tasklet) from running during the normal irq_exit path.  Then, we 
can just use the existing software IRQ replay code, and I think barely 
any new code (queue_irq(), etc) has to be written.
Zach
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |   
 
| <Prev in Thread] | 
Current Thread | 
[Next in Thread>
 |  
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops	callsites to make them patchable, (continued)
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops	callsites to make them patchable, Andreas Kleen
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Ingo Molnar
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Eric W. Biederman
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Rusty Russell
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable,
Zachary Amsden <=
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Linus Torvalds
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
 
    
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Matt Mackall
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Matt Mackall
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Jeremy Fitzhardinge
 
- [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap	paravirt ops callsites to make them patchable, Andi Kleen
 - [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable, Zachary Amsden
 
 
 |  
  
 | 
    |