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

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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