WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] FYI: userland <-> hypervisor parameter passing
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Thu, 17 Nov 2005 12:53:43 -0600
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 17 Nov 2005 18:54:27 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b0688eacf816e3965ea1528f35efd9c0@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <200511161724.57284.hollisb@xxxxxxxxxx> <b0688eacf816e3965ea1528f35efd9c0@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
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