Re: [Xen-devel] [PATCH 2/2] xen-gntalloc: Userspace grant allocation driver

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 12/08/2010 11:47 AM, Ian Campbell wrote:
> On Fri, 2010-12-03 at 15:38 +0000, Daniel De Graaf wrote:
>> This allows a userspace application to allocate a shared page for
>> implementing inter-domain communication or device drivers. These
>> shared pages can be mapped using the gntdev device or by the kernel
>> in another domain.
> 
> This seems like useful functionality but is it really necessary for it
> to be a separate driver to the existing gntdev driver? The broad high
> level semantics of ioctl+mmap seem pretty similar. It also has some
> similarities with the sort of device we will need in order to properly
> allocate memory which is safe to use as an argument to a hypercall.

The functionality is similar enough that I considered changing this to
additional ioctl() in the gntdev device, but decided to leave them split
because the semantics of creating a shared page are slightly more dangerous
than simply mapping pages from other domains.

As noted in the driver, due to a limitation of Xen's grant table API, there
is no way for a guest to force other guests to unmap shared pages once they
have been mapped. This means that if a userspace application using gntalloc
crashes, the other end may not notice and would keep the page mapped until
another event (application restarts and requests peers to clean up old
session, or the peer itself terminates and unmaps the pages). This will use
up both guest memory and space in the grant table (normally limited to 32
pages, so the limit on gntalloc will not allow exhaustion).

If the devices are distinct, it is possible to allow applications access to
one without allowing access to both; I am not aware of any easy way to do this
if they are both implemented by similar ioctl()/mmap() calls on a single
device node.

A hypercall-safe memory allocation device will likely share code from this
device, as it shares some of the mapping code with gntdev. Are there existing
patches for the hypercall buffer allocation? It may be useful to try to factor
out a some common code for dealing with pages used to communicate between Xen
and userspace.

> Do you have an example of a user of the driver?

I do have an communication library (vchan, based on code from Qubes); I am
currently modifying it to allow the use of more than one page for the ring
to reduce context switches when passing large amounts of data (this cost is
increased due to both ends being in userspace, rather than kernel space). If
that isn't ready soon, I will just post the version of vchan using this
device and the modified gntdev API.

> Thanks,
> Ian.
> 

-- 
Daniel De Graaf
National Security Agency

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