Re: passing hypercall parameters by pointer

[Arun Sharma <arun.sharma@intel.com>]

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:

http://article.gmane.org/gmane.comp.emulators.xen.devel/11107

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).

	-Arun