This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [patch] 32/64-bit hypercall interface revisited
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 27 Apr 2006 13:51:07 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Hollis Blanchard <hollisb@xxxxxxxxxx>, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Apr 2006 22:51:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZpDpL4rwxvvFAfRdaTyL2N9atmRgAr+Ctw
Thread-topic: [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)
>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
>be hidden behind the pre-allocation interface.
>  -- Keir

Thanks for info, and it helps.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>