Re: FIFO-based event channel ABI design (draft B)

[David Vrabel <david.vrabel@citrix.com>]

On 15/02/13 15:05, Jan Beulich wrote:
>>>> On 15.02.13 at 15:32, David Vrabel <david.vrabel@citrix.com> 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