| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] fooey. no interrupts.
>
> I've just realized a few days ago, when I get back to xen/plan 9, that I'm
> not getting interrupts after the first few. This with a very recent pull.
> What's amazing that it got as far as it did, but I am processing pending
> interrupt stuff in spllo() so that explains a lot. What I'm not getting is
> the asynchronous calls to evtchn_do_upcall.
>
> The mask is zero. I've enabled VIRQ_TIMER. Yet I'm only getting one set of
> interrupts and it looks like no more. My loop for picking up events is
> pretty much the same as the linux loop -- I just took that code. I am
> clearing out evtchn_upcall_pending and evtchn_pending_sel. I am clearing
> the mask to 0 at the end of the interrupt.
>
> What's a reasonable set of things to look for? I'm stumped.
The Linux code sets the evtchn_mask before clearing evtchn_pending,
then clears the evtchn_mask after calling the interrupt handler. Are
you doing the setting but forgetting the clearing?
The order that Linux has for this stuff, to avoid races, is:
1. Test-and-clear evtchn_upcall_pending flag
2. Read-and-clear (XCHG) the evtchn_pending_sel
3. For each set bit @i in the sel:
4. Read evtchn_pending[@i]
5. For each set bit @j in the word:
6. Set evtchn_mask[@i*32+@j]
7. Clear evtchn_pending[@i*32+@j]
8. ....do interrupt work...
9. Clear evtchn_msk[@i*32+@j]
The fact that step 2 is a real XCHG instruction is important, as it
also acts as a memory barrier (not important if you're not running on
an SMP machine). Also, all your bit-munging instructions must have the
LOCK prefix if you're running on an SMP machine.
Unmasking evtchn_upcall_mask and evtchn_mask[] need special attention
because a pending interrupt will not automatically get raised as it
would on real hardware ---- think of it like an edge-triggered
interrupt where you lost the edge because the line was masked. So what
we do in Linux is:
Clearing evtchn_upcall_mask:
1. Clear evtchn_upcall_mask
2. Barrier [just a compiler barrier, not a CPU barrier]
3. If ( evtchn_upcall_pending) do_evtchn_processing()
Clearing evtchn_mask[]:
A bit more involved; see unmask_evtchn() in include/asm-xen/evtchn.h
Sticking close to the Linux code, and making sure the underlying
bitops are LOCKed, is important! I guess yours is unlikely to be a
subtle race if you only ever receive precisly one VIRQ. :-)
-- Keir
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home