[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xenbus_backend_client.c / xenbus_client.c merger



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.