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


Re: [Xen-devel] passing hypercall parameters by pointer

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] passing hypercall parameters by pointer
From: Arun Sharma <arun.sharma@xxxxxxxxx>
Date: Wed, 17 Aug 2005 14:07:08 -0700
Cc: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Wed, 17 Aug 2005 21:05:23 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <mailman.1124311483.4826@xxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D282BB8@xxxxxxxxxxxxxxxxxxxxxxxxxxx> None None <mailman.1124311483.4826@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
Ian Pratt wrote:
Many Xen hypercalls pass mlocked pointers as parameters for both input and output. For example, xc_get_pfn_list() is a nice one with multiple levels of structures/mlocking.

Considering just the tools for the moment, those pointers are userspace addresses. Ultimately the hypervisor ends up with that userspace address, from which it reads and writes data. This is OK for x86, since userspace, kernel, and hypervisor all share the same virtual address space (and userspace has carefully mlocked the relevent memory).

This is a problem even on x86 for VMX domains which execute hypercalls because of para virtualized device drivers.

On PowerPC though, the hypervisor runs in real mode (no MMU translation). Unlike x86, PowerPC exceptions arrive in real mode, and also PowerPC does not force a TLB flush when switching between real and virtual modes. So a virtual address is pretty much worthless as a hypervisor parameter; performing the MMU translation in software is infeasible.

I think I'd prefer to hide all of this by co-operation between the
kernel and the hypervisor's copy to/from user.

This is basically what Xiaofeng attempted to do in this patch:


although the virtual -> pseudo physical is also done in the hypervisor.
Please let us know if the patch is acceptable in light of your email.

The kernel can easily translate a virtual address and length into a list
of psuedo-phyiscal frame numbers and initial offset. Xen's copy from
user function can then use this list when doing its work.

The other alternative (which we talked about at OLS) is to use a couple of pinned pages for parameter passing - but it doesn't work very well for:

a) Multiple levels of structures/pointers
b) Arguments which may be bigger than a couple of pages (xc_get_pfn_list() for a bigmem domain for example).


Xen-devel mailing list