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 13/26] Xen-paravirt_ops: Consistently wrap paravi

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 20 Mar 2007 19:15:15 -0700 (PDT)
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: Wed, 21 Mar 2007 02:29:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46009E42.30400@xxxxxxxxxx>
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> <46009E42.30400@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Tue, 20 Mar 2007, Zachary Amsden wrote:
> 
> 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.

No can do. Think level-triggered. You *need* to disable the interrupt, and 
disabling it at the CPU is the easiest approach. Even so, you need to 
worry about SMP and screaming interrupts at all CPU's, but if you don't 
ack it to the IO-APIC until later, that should be ok (alternatively, you 
need to just mask-and-ack the irq controller).

> Maybe leaving irqs disabled is better.

One of the advantages of doing that is that you only ever have a queue of 
one single entry, which then makes it easier to do the replay.

                Linus

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

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