From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Xen spinlock questions
Date: Mon, 11 Aug 2008 11:49:09 -0700
Message-ID: <48A089A5.2090200@goop.org>
References: <C4C64402.1C15E%keir.fraser@eu.citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C4C64402.1C15E%keir.fraser@eu.citrix.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

Keir Fraser wrote:
> That's right. The hypercall returns if any event is delivered to the vcpu,
> or if any port in the poll set is pending. The fact we don't clear the vcpu
> from the poll_mask if unblocked for event delivery isn't a correctness
> issue, but it will cause unnecessary extra work in future invocations of
> evtchn_set_pending(). Perhaps vcpu_unblock() should clear it.
>   

That seems reasonable.  In this use-case, it's quite likely that if the 
poll is interrupted by event delivery, on return it will find that the 
spinlock is now free and never re-enter the poll.

    J