| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [patch] 32/64-bit hypercall interface revisited
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2006年4月26日 16:47
>
>
>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
Thanks for info, and it helps.
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home