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/
Home Products Support Community News


[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravi

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
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 14:09:13 -0800
Cc: 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, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, David Miller <davem@xxxxxxxxxxxxx>
Delivery-date: Tue, 20 Mar 2007 15:08:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46000C7E.4070001@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/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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20070221)
Jeremy Fitzhardinge wrote:

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 */

Well, can't do xchg, since it implies #LOCK, and you'll lose more than you gain on the processors where it matters. Cmpxchg is fine, but processor dependent.

Or, just make the interrupt handlers use software resend for IRQs when pda.intr_mask is set to zero. Now, local_irq_save / restore are very pretty:

int local_irq_save(void)
  int tmp = pda.intr_mask;
  pda.intr_mask = 0;
   * note there is a window here where local IRQs notice intr_mask == 0
   * in that case, they will attempt to resend the IRQ via a tasklet,
   * and will succeed, albeit through a slightly longer path
  return tmp;

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)

I think Ingo's suggestion of using the hardirq tracing is another way that could work, but it seems to be too heavyweight and tied too much to the lockdep verification code - plus it inserts additional raw_irq_disable in places that seem counter to the goal of getting rid of them in the first place. Perhaps I'm misunderstanding the code, though.


Xen-devel mailing list

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