From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 3/3] evtchn/fifo: don't spin indefinitely when setting LINK Date: Wed, 6 Nov 2013 15:07:14 +0000 Message-ID: <527A5B22.5040503@citrix.com> References: <1383231791-4604-1-git-send-email-david.vrabel@citrix.com> <1383231791-4604-4-git-send-email-david.vrabel@citrix.com> <527A465A.2010806@citrix.com> <527A59E1.7070002@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <527A59E1.7070002@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: Keir Fraser , David Vrabel , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/11/13 15:01, Boris Ostrovsky wrote: > On 11/06/2013 08:38 AM, David Vrabel wrote: >> >> Given the non-obvious locking required for this to be safe and the >> overhead of the guest having to do a unmask hypercall more often. I >> think I will fix this differently. >> >> A new BUSY bit is added to the event word. Xen sets BUSY prior to >> updating the LINK field and then clears it when the LINK field is set. >> >> When the guest unmasks an event it must spin waiting for BUSY to clear >> before it clears the MASKED bit. It then need only do the unmask >> hypercall if the event is pending (as before). >> >> Draft H and v3 of this series to follow. > > Will there be a new Linux series as well? Yes, but only the final patch in the series will change. David