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: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [Xen-devel] FYI: userland <-> hypervisor parameter passing
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 17 Nov 2005 10:45:14 +0000
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 17 Nov 2005 10:39:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200511161724.57284.hollisb@xxxxxxxxxx>
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>
References: <200511161724.57284.hollisb@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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