[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 > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |