[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |