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 17:07:29 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Feb 2007 09:06:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1FF85CA.9B43%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: <C1FF85CA.9B43%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2007-02-19 at 16:50 +0000, Keir Fraser wrote:
> On 19/2/07 16:08, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> 
> > 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.
> 
> 
> Okay, if we go this way then the functions probably need to be given more
> general names (since they are not used just for descriptor rings any more)
> and also will you not need them to generalise to accepting more than one
> grant reference (since you want to map two grant references into a two-page
> vm area)?

I'm happy to make that change.  An alternative (and much smaller) change
would be to leave the existing map_ring API alone and augment with a
functionally similar version that could be used by the front end, and
was called something else to avoid confusion.  This would be my
preferred option I think, and would remove the need to move code out of
xenbus_backend_client. 

Accepting one grant reference is not a big deal - I can just get a grant
per page and pass all the grants, then allocate a two page vm_area map
the individual grants at the appropriate offsets into that area to get
them virtually contiguous.

Kieran


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