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: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 20 Mar 2007 09:31:58 -0700
Cc: Zachary Amsden <zach@xxxxxxxxxx>, 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 09:30:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0703200903500.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.10 (X11/20070302)
Linus Torvalds wrote:
> On Tue, 20 Mar 2007, Eric W. Biederman wrote:
>   
>> If that is the case.  In the normal kernel what would
>> the "the oops, we got an interrupt code do?"
>> I assume it would leave interrupts disabled when it returns?
>> Like we currently do with the delayed disable of normal interrupts?
>>     
>
> Yeah, disable interrupts, and set a flag that the fake "sti" can test, and 
> just return without doing anything.
>
> (You may or may not also need to do extra work to Ack the hardware 
> interrupt etc, which may be irq-controller specific. Once the CPU has 
> accepted the interrupt, you may not be able to just leave it dangling)
>   

So it would be something like:

    pda.intr_mask = 1;          /* disable interrupts */
    ...
    pda.intr_mask = 0;          /* enable interrupts */
    if (xchg(&pda.intr_pending, 0))     /* check pending */
        asm("sti");             /* was pending; isr left cpu interrupts masked 
*/
      

and in the interrupt handler:

    if (pda.intr_mask) {
        pda.intr_pending = 1;
        regs->eflags &= ~IF;
        maybe_ack_interrupt_controller();
        iret
      

    }

?

    J


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

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