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


[Xen-devel] Question about pirq_guest_unmask

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Question about pirq_guest_unmask
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 27 Apr 2006 20:16:28 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 27 Apr 2006 05:16:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZp9Gg9Tlrk+ou/Q5iVp+aezNwM7g==
Thread-topic: Question about pirq_guest_unmask
Hi, Keir,
        Though the logic to handle pirq has been enhanced recently, 
there's one point never changed which seems questionable to me. 
Why does pirq_guest_unmask need to scan all pirq_masks instead 
of the one that guest is exactly requesting? Does it aim to accelerate 
EOI when another vcpu is sitting between unmask_evtchn and 

        There seems to be a race condition by current logic:

        if ( (action->ack_type != ACKTYPE_NONE) &&
             !test_and_set_bit(irq, &d->pirq_mask) )
    send_guest_pirq(d, irq);
<- At this point, the pirq_mask is set, while the evtchn_mask is likely 
to be cleared. Evtchn_mask will be set later when target vcpu is 
scheduled and ack_pirq is issued.

While in pirq_guest_unmask:
        For all bits set in pirq_mask:
                if ( !test_bit(d->pirq_to_evtchn[pirq],
&s->evtchn_mask[0]) &&
             test_and_clear_bit(pirq, &d->pirq_mask) )

Above logic in pirq_guest_unmask tempts to consider clearing related 
event mask as an indicator for subsequent pirq unmask request. 
However it's possible for above checking happening right between 
send_guest_irq and ack_pirq for another pirq injection.

If that's the case, it's possible for one EOI issued early than
Does I miss anything important? Is it OK to change it to service desired

pirq only?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>