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

[Xen-devel] Re: user/hypervisor address space solution

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: user/hypervisor address space solution
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 14 Feb 2006 11:06:47 +1100
Cc: Dan Magenheimer <dan.magenheimer@xxxxxx>, Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefan Berger <stefanb@xxxxxxxxxx>, Reiner Sailer <sailer@xxxxxxxxxx>
Delivery-date: Tue, 14 Feb 2006 00:30:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a563728faeb7ad2225b8a8ee3a79efb5@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: <1139283935.13776.71.camel@xxxxxxxxxxxxxxxxxxxxx> <d03c55d46049b70da00eaf3672ccd153@xxxxxxxxxxxx> <1139871396.8407.124.camel@xxxxxxxxxxxxxxxxxxxxx> <a563728faeb7ad2225b8a8ee3a79efb5@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2006-02-13 at 23:45 +0000, Keir Fraser wrote:
> On 13 Feb 2006, at 22:56, Hollis Blanchard wrote:
> 
> > There are very few uses of get/put_user() in common code right now, and
> > those can be trivially converted. However, there are some in arch code
> > e.g. xen/arch/x86/domain.c) that cannot, and so the current put_user
> > interface would need to be preserved as some arch-specific macro. In
> > this case I'd call it "x86_put_user" to emphasize that only x86 arch
> > code should be using it. Too many x86isms creep into places like
> > grant_table.c...
> 
> I expect copy_to/from_user would also need to change. There are places 
> where an array of structs are passed to a hcall, a pointer into that 
> array is passed around in Xen, and individual array entries are copied 
> in/out.

Hmm, I didn't run across that; can you point me to some code? At any
rate, changing "struct foo *entry" to "struct foo *array, int index" in
the function parameter lists shouldn't be a big deal.

> However, this approach seems little different on the Xen side from the 
> xencomm allocator approach -- the pointers are still opaque handles 
> from the p.o.v. of generic Xen code. So some interface changes would be 
> required even if we went down that road.
> 
> This opacity should probably be represented in the public header file 
> definitions and in the prototypes of uaccess functions, instead of 
> pretending the handles are really 'foo *' pointers. That would help 
> clean up all uses of the uaccess functions in Xen.

Ok, so what I'm hearing is that copy_to/from_user() and get/put_user()
should take unsigned long and not void*.

> We'll have to see how this all pans out....

This is my biggest issue and it's blocking me; I am trying to solve it
now. If you are amenable to the get/put_user() changes I described, I
will go ahead and implement them today.

-- 
Hollis Blanchard
IBM Linux Technology Center


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