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

[Kieran Mansley <kmansley@xxxxxxxxxxxxxx>]

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