Re: [Xen-devel] FYI: userland <-> hypervisor parameter passing

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 16 Nov 2005, at 23:24, Hollis Blanchard wrote:

> Instead, this patch has userspace allocate all structures from the 
> same page,
> with some translation information stuffed at the base of the page. 
> Userland
> records the virtual base of the page, and the kernel records the 
> physical
> base. (We have not yet implemented the pfn2mfn macros, but the 
> hypervisor can
> easily convert physical->machine addresses.) The Xen 
> copy_to/from_user()
> functions operate on virtual addresses, masking with PAGE_SIZE to find 
> the
> needed translation information. This translation is currently only 
> done for
> dom0_op and memory_op hcalls, which are the offenders I've run into so 
> far.
I think it'd be cleaner to have a completely separate 'xencomm' 
communications address space. Then xencomm_alloc() would return two 
pointers:
 1. Local virtual address that caller can use to read/write the 
allocated block.
 2. xencomm pointer that gets passed to Xen during hypercall

Your new_xencomm() allocates a new page of memory, then passes the MFN 
to Xen as part of a new 'allocate xencomm addr space' hypercall. Xen 
returns the allocated xencomm address for that MFN (or batch of MFNs), 
thus establishing the xencomm<->machine mapping in both Xen and in the 
guest.
copy_to_user/copy_from_user and friends all expect the user pointer to 
be in xencomm address space, and will do a xencomm->xen-virtual-address 
translation (the xen-virtual-address mapping is created during the 
establish hypercall described above).
The above is what I intend to implement for x86 after 3.0 (it's easy to 
maintain backward compatibility), so as long as any proposed generic 
interface allows the above implementation then I'm happy.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel