From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH 0/2] Userspace grant communication Date: Fri, 03 Dec 2010 13:27:54 -0500 Message-ID: <4CF936AA.3010805@tycho.nsa.gov> References: <4CF90E71.5020909@tycho.nsa.gov> <20101203163054.GA2754@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20101203163054.GA2754@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 12/03/2010 11:30 AM, Pasi K=E4rkk=E4inen wrote: > On Fri, Dec 03, 2010 at 10:36:17AM -0500, Daniel De Graaf wrote: >> For fast communication between userspace applications in different dom= ains, >> it is useful to be able to set up a shared memory page. This can be us= ed to >> implement device driver frontends and backends completely in userspace= , or >> as a faster alternative to network communication. The current gntdev i= s >> limited to PV domains, and does not allow grants to be created. The fo= llowing >> patches change gntdev to remapping existing pages, allowing the same c= ode >> to be used in PV and HVM, and add a gntalloc driver to allow mappings = to be >> created by userspace. These changes also make the mappings more applic= ation- >> friendly: the mmap() calls can be made multiple times, persist across = fork(), >> and allow the device to be closed without invalidating the mapped area= s. This >> matches the behavior of mmap() on a normal file. >> >=20 > Btw are you aware of the new fast inter-domain communication method in = XenClient ? >=20 > -- Pasi >=20 No, I have not looked at that; is there a whitepaper or some information = on it? If not, a pointer to the relevant source would be of interest. - Daniel >=20 >> API changes from the existing /dev/xen/gntdev: >> >> The unused "pad" field in ioctl_gntdev_map_grant_ref is now used for f= lags >> on the mapping (currently used to specify if the mapping should be wri= table). >> This provides sufficient information to perform the mapping when the i= octl is >> called. To retain compatibility with current userspace, a new ioctl nu= mber is >> used for this functionality and the legacy error on first mapping is r= etained >> when the old ioctl is used. >> >> IOCTL_GNTDEV_SET_MAX_GRANTS is not exposed in the Xen userspace librar= ies, >> and is not very useful: it cannot be used to raise the limit of grants= per >> file descriptor, and is trivial to bypass by opening the device multip= le >> times. This version uses a global limit specified as a module paramete= r >> (modifiable at runtime via sysfs). >> >> --=20 >> Daniel De Graaf >> National Security Agency >> >=20