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 1/9] Add cpu idle pwr mgmt to xen

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 1/9] Add cpu idle pwr mgmt to xen
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 30 Apr 2008 17:42:37 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Wed, 30 Apr 2008 02:43:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4818597B.76E4.0078.0@xxxxxxxxxx>
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>
References: <48183A3F.76E4.0078.0@xxxxxxxxxx> <C43DF247.20177%keir.fraser@xxxxxxxxxxxxx> <D470B4E54465E3469E2ABBC5AFAC390F024D9217@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4818597B.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciqpXdFIt+C8IwQS7OhFvTNNKD8/gAABqMg
Thread-topic: [Xen-devel] [PATCH 1/9] Add cpu idle pwr mgmt to xen
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年4月30日 17:35
>>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 30.04.08 11:12 >>>
>>One thing kicking me just now is, whether Linux address check
>>style can be used here by temporarily increasing address limit
>>in compat logic to bypass relative check in common code? I
>>didn't see obvious benefit to reserve a guest virtual addr range
>>and let each component to manage internal allocation themselves.
>>Linux style seems simpler and compat logic can just use xmalloc
>>to create native copy to reduce xlat complexity.
>I intentionally did not go that route when I first wrote these 
>routines. For one, you wouldn't be able to partly copy things (as I
>suggested as an improvement here), since the validity checks would
>apply to all or nothing during an individual hypercall (and a 
>bad 64-bit
>field representing a pointer might then slip through). Secondly, the

What do you mean by partly copying things? For a 32-on-64 guest,
all pointers from guest are 32-bit and compat_handler_okay already
ensures compat pointers validity. Only native structure may have 
64-bit pointer field, which is checked by common guest_handle_okay
if from a 64bit guest, or is trusted by increasing addr limitation if
from compat layer...

>static pre-allocation used currently also avoids spurious failures of
>hypercalls (there may be deterministic failures if the combined set
>of indirect hypercall arguments exceeds the pre-allocation size.

That's also the limitation of current approach by pre-defined size, which
is not scalable if 2nd level pointer are variable decided by some count


Xen-devel mailing list