Re: [Xen-devel] fooey. no interrupts.
Further thinking about the whole interrupt thing. It seems to me that all
the interrupts are edge-triggered, see:
* 2. MASK -- if this bit is clear then a 0->1 transition of PENDING
* will cause an asynchronous upcall to be scheduled. This bit is
* updated by the guest. It is read-only within Xen. If a channel
* becomes pending while the channel is masked then the 'edge' is
* (i.e., when the channel is unmasked, the guest must manually
* pending notifications as no upcall will be scheduled by Xen).
But what we want in some cases (timer in particular) are level interrupts.
So this code:
static inline void evtchn_set_pending(struct domain *d, int port)
shared_info_t *s = d->shared_info;
if ( !test_and_set_bit(port, &s->evtchn_pending) &&
!test_bit (port, &s->evtchn_mask) &&
!test_and_set_bit(port>>5, &s->evtchn_pending_sel) )
is really testing for edges (which is fine) but in some cases we really do
want a level.
Sadly this does complicate life but at the same time I'd argue that
VIRQ_TIMER should be a level interrupt. I can't see any way out of this
race condition otherwise.
Does this make sense or am I totally off base? I do think the comment
above (from hypervisor-if.h) very clearly explains the potential race
condition. I've fallen into it in a big way, but I think it is a problem
others may fall into as well.
I'm going to add a trivial function evtchn_set_pending_level and call it
out of send_guest_virq and see if it helps my problem. My guess is it
Thanks for your patience on this one, Keir.
LANL CCS-1 email flavor:
***** Correspondence 
***** DUSA LACSI-HW [ ]
***** DUSA LACSI-OS [x ]
***** DUSA LACSI-CS [ ]
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
Xen-devel mailing list