This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: ron minnich <rminnich@xxxxxxxx>
Subject: Re: [Xen-devel] fooey. no interrupts.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 10 Aug 2004 10:07:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 10 Aug 2004 10:10:28 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Mon, 09 Aug 2004 21:40:41 MDT." <Pine.LNX.4.44.0408092130560.2554-100000@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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