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

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Thursday 17 November 2005 04:45, Keir Fraser wrote:
>
> 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.

Ok, so all the nested pointers will be in the machine address space. I think 
that will require some rework of the layering in xc_private.c, since 
functions like xc_add_mmu_update() dereference the pointers they're passed.

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

Perfectly reasonable. If it didn't require so much out-of-tree libxc hacking, 
I would volunteer to implement this design right now.

So I think I should leave the PPC implementation as-is for now, but I will be 
looking forward to post-3.0 (as I suppose we all will, for various 
reasons ;) .

-- 
Hollis Blanchard
IBM Linux Technology Center

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