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] xenbus_backend_client.c / xenbus_client.c merger

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xenbus_backend_client.c / xenbus_client.c merger
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Mon, 19 Feb 2007 16:08:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Feb 2007 08:08:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1FF6FEE.9B06%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C1FF6FEE.9B06%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2007-02-19 at 15:17 +0000, Keir Fraser wrote:
> On 19/2/07 14:00, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> 
> > Although I don't know the full history, it looks like at some point
> > linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_backend_client.c was
> > created to hold "backend only" code that would otherwise be in
> > linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_client.c.
> > 
> > However, the code in xenbus_backend_client.c isn't currently specific to
> > the backend - it just happens to be that no frontends use it.  At least
> > that's how it looks to me.
> 
> Currently we have a model that frontends supply memory for ring buffers,
> which backends map into their kernel address space.

Which is on the whole a very good idea.

> Where is the memory
> coming from that your frontend maps?

It's host memory in dom0 which is also passed to our virtualisable
network interface cards.  The reason it's allocated by the backend in
dom0 rather than using the model above is that we need to be able to
allocate two physically contiguous pages, and I this would be tricky
from domU.  If you know of a way of doing this, that would be an
excellent alternative to needing to use the xenbus_backend_client code
in the frontend.

Technically we're not using the mapped memory as a ring buffer, but
xenbus_map_ring and friends are a convenient API to grants and mapping
them.

> Is it appropriate to be using grant
> table entries to refer to and map that memory?

I wasn't aware of an alternative mechanism so I'll hazard a "yes, it is
appropriate".  However, if given the above information you think
otherwise, let me know.

Kieran


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