[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] fooey. no interrupts.

> 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 
> will. 

If you use this function (from evtchn.h) to unmask individual event
channels then you will not experience the race. Changes to Xen are not

[NB. sync_*_bit forces uses of SMP-safe atomic bit operations (ie., on 
 x86 they will use the LOCK prefix). I need to deliberately specify
 this because the guest OS is UP, and so it's usual *_bit operations
 are not SMP-safe! You may want to watch out for this one yourself.]

static inline void unmask_evtchn(int port)
    shared_info_t *s = HYPERVISOR_shared_info;

    synch_clear_bit(port, &s->evtchn_mask[0]);

     * The following is basically the equivalent of 'hw_resend_irq'. Just
     * like a real IO-APIC we 'lose the interrupt edge' if the channel is
     * masked.
    if (  synch_test_bit        (port,    &s->evtchn_pending[0]) && 
         !synch_test_and_set_bit(port>>5, &s->evtchn_pending_sel) )
        s->vcpu_data[0].evtchn_upcall_pending = 1;
        if ( !s->vcpu_data[0].evtchn_upcall_mask )

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.