| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] passing hypercall parameters by pointer
On Aug 19, 2005, at 7:17 AM, Keir Fraser wrote:
On 19 Aug 2005, at 12:52, Jimi Xenidis wrote:
IP> Since passing by VA is so convenient on the architectures that
IP> support it we may not want to do anything different on these
IP> anyhow.
I agree, why create a new mapping when a usable one exists.
At least for common kernel code, we will need to wrap such VAs in a
macro so that the "psuedo-physical" is passed in for PPC. I assume
this is reasonable?
This is all potentially fixable before 3.0 final. Paravirt x86 can
continue to use guest virtual addresses. The idea would be that the
registration scheme would essentially create a parameter-passing
'address space' into which you hook pages of memory. On x86 we would
map the address space onto regions of kernel va space. On other arches
we would map the address space onto physical addresses that get mapped
into Xen's va space. get_user/put_user/copy_from_user/copy_to_user
will take guest addresses that point into this parameter-passing
address space.
Could you flesh this out a little more? I *think* what you're saying is
this (on PowerPC):
- at boot, the kernel notifies Xen of a parameter page
- replace libxc calls to mlock() with register_this_address() (which
could be a privcmd ioctl)
- register_this_address() stuffs the userspace pointer and
corresponding pseudo-physical pointer into a table in the parameter
page
- libxc ignorantly creates its structures with userspace addresses
- once the hypercall arrives in Xen, copy_from_user() is passed the
userspace address
- copy_from_user() consults the table in the parameter page to
translate userspace -> pseudo-physical, then translates pseudo-physical
-> machine
Is that right?
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home