Messages in this thread | | | Date | Tue, 20 Mar 2007 17:24:58 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable |
| |
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.
But since it's all a local-cpu issue, you can do things like test cpu-local memory flags for whetehr that has happened or not.
So it *should* be something as simple as
local_irq_disable() { pda.irq_enable = 0; }
handle_interrupt() { if (!pda.irq_enable) { pda.irq_queued = 1; queue_interrupt(); .. make sure we return with hardirq's now disabled: just clear IF in the pt_regs .. return; } .. normal .. }
local_irq_enable() { pda.irq_enable = 1; barrier(); /* Common case - nothing happened while we were fake-disabled.. */ if (!pda.irq_queued) return;
/* Ok, actually handle the things! */ handle_queued_irqs();
/* * And enable the hw interrupts again, they got disabled * when we were queueing stuff.. */ hardware_sti(); }
but I haven't really gone over it in any detail, I may have missed something really obvious.
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?
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |