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 16:42:26 -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 13:45:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1319574443.16747.1.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>
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: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. 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.

-- 
Daniel De Graaf
National Security Agency

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