[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] FYI: userland <-> hypervisor parameter passing
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
> 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
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 ;) .
IBM Linux Technology Center
Xen-devel mailing list