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

[Xen-devel] Re: [PATCH 00 of 25] libxc: Hypercall buffers



On Thu, 2010-10-21 at 11:58 +0100, Ian Campbell wrote:
> 
> This series addresses (1) and (2) but does not directly address (3)
> other than by encapsulating the code which acquires hypercall safe
> memory into one place where it can be more easily fixed.

WRT solving (3) the approach which I am considering is to implement a
new misc device (e.g. /dev/xen/hypercall). The device would support mmap
which would provide suitably locked etc memory for use as a hypercall
argument as well as supporting the existing IOCTL_PRIVCMD_HYPERCALL
on /proc/xen/privcmd (deprecating that ioctl on privcmd).

There are a couple of reasons for the new device instead of extending
the existing privcmd, firstly I think it's generally a more upstream
friendly/acceptable interface and secondly privcmd already implements
mmap as part 1 of the 2 part IOCTL_PRIVCMD_MMAP thing which makes
retrofitting the desired new behaviour in a forwards/backwards
compatible way a bit difficult.

It might also be nice to migrate IOCTL_PRIVCMD_MMAP* over (or a single
generic interface subsuming them) to /dev/xen as well, either as part of
this new device or a new /dev/xen/m(achine)mem or similar. This would
allow deprecation of /proc/xen/privcmd entirely.

Opinions?

Ian.


_______________________________________________
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®.