[Xen-ia64-devel] Re: Any hint about a weird behavior about scheduler?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 25 Jan 2006, at 03:36, Tian, Kevin wrote:

>         The possible reason seems from your recent change to reduce lock
> critical region in __enter_scheduler, where spin_unlock_irq is promoted
> to the point before context_switch. That's obvious good, however to
> leave a small window with interrupt enabled which may not be handled
> correctly by current ia64 code. To move spin_unlock_irq backward after
> context_switch, everything works well then.
>
>         So Keir, have you seen any similar phenomenon per your
> experience before? If yes, how about the cause? That may be different 
> as
> IA64, which however provide invaluable hint to help track down bogus
> code on IA64.
I haven't seen this on x86. My gut feeling is that perhaps you are 
executing softirq work Linux style rather than Xen style.
That is: Linux is happy to execute softirq work at the tail of a 
hardirq, as long as it is the outermost hardirq context. In contrast, 
Xen expects softirqs only to be executed in the outermost Xen 
activation. So, for example, Xen does not check for softirq reentrancy 
in do_softirq, because that is never expected to happen. But even if 
you did add a reentrancy check you would risk deadlock (since you may 
interrupt e.g., hypercall context while it has a lock held, and that 
lock may be shared with code that is executed in softirq context).
Removing do_softirq() from irq_exit() will probably fix this problem 
for you, and generally improve correctness.
 -- Keir


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