Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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 
>translation
>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
field.

Thanks,
Kevin

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