From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: FIFO-based event channel ABI design (draft B) Date: Fri, 15 Feb 2013 15:17:56 +0000 Message-ID: <511E51A4.9020503@citrix.com> References: <511E46FD.3010605@citrix.com> <511E5CD202000078000BEC4F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <511E5CD202000078000BEC4F@nat28.tlf.novell.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: Jan Beulich Cc: Wei Liu , xen-devel List-Id: xen-devel@lists.xenproject.org On 15/02/13 15:05, Jan Beulich wrote: >>>> On 15.02.13 at 15:32, David Vrabel wrote: >> ### Control Block >> >> ![\label{fig_control-block}Control Block](control-block.pdf) >> >> The READY field contains a bit for each priority's queue. A set bit >> indicates that there are events pending on that queue. A queue's >> ready bit is set by Xen when an event is placed on an empty queue and >> cleared by the guest when it empties the queue. >> >> There are N HEAD and TAIL indexes, one for each priority. >> >> The HEAD index is the first event in the queue or zero if the queue is >> empty. HEAD is set by the guest as it consumes events and only set by >> Xen when adding an event to an empty queue. >> >> The TAIL index is the last event in the queue. It is undefined if the >> queue is empty. TAIL is only set by Xen. > > One thing I continue to wonder is why tail it part of the control > block at all - from all I can tell, it's not consumed by the guest (end > of list being indicated by a zero LINK field), and hence is an > implementation detail of the hypervisor. And given that the > hypervisor reads that field, not exposing the field also avoids the > need to validate is each time it gets read from the control block. Some of my initial back-of-envelope designs used it and I left it in "just in case". But the validation point is good, so I'll remove the TAIL field. > Additionally, I think the number of significant bits of the LINK field > should actually be obtained from the hypervisor, rather than being > baked at 17 (for the time being). This again is an implementation > detail (and the value could easily be command line controllable). I'd considered something like this but decided to defer this to a future date when it needed to be extended. How about adding an EVTCHNOP_get_limit which gets the maximum permitted port? The guest can then round up the result of this to get the maximum number of LINK bits. David