Xen devel - Apr 2006 - RE: [patch] 32/64-bit hypercall interface revisited

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>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@lists.xensource.com
http://lists.xensource.com/xen-devel