| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [Xen-devel] [patch] 32/64-bit hypercall interface revisited
On 26 Apr 2006, at 09:15, Tian, Kevin wrote:
Could you reveal something about how to kill mlock() completely?
:-) Current mlock() can ensure the ptes related to user buffer existing
in page table, and thus xen can copy from/to that buffer directly. By
removing mlock(), do you mean page fault may be injected to guest
then?
Sorry, I meant that the *current* mlock() strategy needs to go, to be
replaced by pre-allocated mlock()ed (or whatever else is needed to
prepare a buffer for hypercall usage on a particular architecture)
buffers.
This is needed even on x86 because the current strategy of
mlock/munlock of non-page-aligned buffers is not really safe (mlock
isn't nested). We get away with it because it's rather unlikely that
two hypercall requests from two different threads will have arguments
overlapping at page granularity, but it's undesirable.
It's a pain to implement partly because it will change the libxc
interface (callers passing in an array for a hypercall will need to
specially allocate the array, callers returned an array will need to
free it in a special way), or we'll end up with two sets of interface:
one legacy, copying interface and one new higher-speed interface.
Done properly, though, the mechanisms needed for each architecture can
be hidden behind the pre-allocation interface.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home