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

>From: Keir Fraser
>Sent: 2006年4月26日 15:50
>On 25 Apr 2006, at 21:24, Hollis Blanchard wrote:
>Also, no need to use GET_GUEST_HANDLE() in the libxc''s
>read_console
>function. Xen will never update the buffer pointer these days -- it
>always fills the buffer from the start. When we eventually kill the
>mlock() crap and implement it properly, I think GET_GUEST_HANDLE()
>can
>be killed off entirely.
>
>  -- Keir
Hi, Keir,
	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?

	On xen/ia64, the hypercall parameter copy has been an issue 
for a long time, since xen/ia64 only caches virtual TLB and doesn''t 
walk guest page table. Even mlock() can''t ensure 
copy_from/to_guest successful. People are considering either 
injecting page fault to guest and then resume the hypercall, or 
lock parameter pages by using similar mechanism like PPC''s 
proposal. So we''re interested in your idea to see whether applicable 
to xen/ia64.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel