WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Tue, 25 Oct 2011 17:07:30 -0400
Cc: "Keir \(Xen.org\)" <keir@xxxxxxx>, "jeremy@xxxxxxxx" <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 25 Oct 2011 14:08:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1319575831.16747.18.camel@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: National Security Agency
References: <1316207684-19860-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <1318971851-12809-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <1318971851-12809-3-git-send-email-dgdegra@xxxxxxxxxxxxx> <20111024205708.GE2441@xxxxxxxxxxxxxxxxxxx> <4EA5E024.7040708@xxxxxxxxxxxxx> <20111025190231.GD10062@xxxxxxxxxxxxxxxxxxx> <4EA710EB.3030809@xxxxxxxxxxxxx> <1319574443.16747.1.camel@xxxxxxxxxxxxxxxxxxxx> <4EA71F32.9040208@xxxxxxxxxxxxx> <1319575831.16747.18.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0
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