[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.