Re: [Xen-devel] Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 10/25/2011 04:50 PM, Ian Campbell wrote:
> On Tue, 2011-10-25 at 21:42 +0100, Daniel De Graaf wrote:
>> On 10/25/2011 04:27 PM, Ian Campbell wrote:
>>> On Tue, 2011-10-25 at 20:41 +0100, Daniel De Graaf wrote:
>>>>
>>>>>> Hmm. Perhaps have a magic value for refcount (-1?) that indicates
>>>> evtchn_get is not
>>>>>> available. That would become the default value of refcnt, and
>>>> evtchn.c would then
>>>>>> use evtchn_make_refcounted() to change the refcount to 1 and allow
>>>> _get/_put to work.
>>>>>
>>>>> How would that work when the IRQ subsystem (so everything is setup
>>>> in the kernel)
>>>>> gets an event? Would the refcount be for that -1.. oh. You would
>>>> only set
>>>>> the refcnt when the _get/_put calls are made and not when in-kernel
>>>> calls to setup> IRQs are done?
>>>>>
>>>>
>>>> Right. The reference count would be a dual-purpose field indicating if
>>>> the event channel is kernel-internal (value -1) or userspace-visible
>>>> (reference count > 0). New event channels would start out at -1, and
>>>> evtchn.c would change them to 1. 
>>>
>>> Is there any way that the reference count could be made part of the
>>> datastructures associated with the /dev/xen/evtchn driver instead of the
>>> core evtchn.c stuff? That wouldreduce the chance of current or futures
>>> users getting something wrong.
>>>
>>> Ian.
>>
>> This would require that the gntdev and gntalloc modules have a dependency
>> on the evtchn module, with the evtchn_{get,put} functions moved into that
>> module.
> 
> Don't they effectively have that already, since the only evtchns you can
> use with them have come from that module?
> 

Yes, but the primary purpose of the gntdev/gntalloc modules does not include
using event channels (just mapping memory). In practice, however, this is
true as shared-memory rings need a notification mechanism if you want to avoid
polling.

>>  The only other way would be to add a refcount maintenance
>> function pointer to the IRQ data structure, which seems like it would lead
>> to more problems than a simple reference count.
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel