This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 00 of 25] libxc: Hypercall buffers
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 22 Oct 2010 13:06:50 +0100
Delivery-date: Fri, 22 Oct 2010 05:07:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <patchbomb.1287658723@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <patchbomb.1287658723@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>