[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: user/hypervisor address space solution
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |