[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
- To: Matt Mackall <mpm@xxxxxxxxxxx>
- From: Zachary Amsden <zach@xxxxxxxxxx>
- Date: Tue, 20 Mar 2007 15:08:19 -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, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, David Miller <davem@xxxxxxxxxxxxx>
- Delivery-date: Tue, 20 Mar 2007 16:07:43 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
Matt Mackall wrote:
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get set after this */
Why not? Oh, I see. intr_mask is inverted form of EFLAGS_IF.
if (unlikely(pda.intr_pending)) {
pda.intr_pending = 0;
asm("sti");
}
(This would actually need a C barrier, but I'll ignore that as this'd
end up being asm...)
But other interesting things could happen. If we never did a real CLI
and we get preempted and switched to another CPU between clearing
intr_mask and checking intr_pending, we get a little confused.
I think Jeremy's idea was to have interrupt handlers leave interrupts
disabled on exit if pda.intr_mask was set. In which case, they would
bypass all work and we could never get preempted. I don't think leaving
hardware interrupts disabled for such a long time is good though.
But perhaps that doesn't matter because we'd by definition have no
pending interrupts on either processor?
Is it expensive to do an STI if interrupts are already enabled?
Yes.
Zach
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
