RE: [Xen-devel] [PATCH 1/9] Add cpu idle pwr mgmt to xen

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年4月30日 18:25
>
>>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 30.04.08 11:42 >>>
>>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...
>
>VCPUOP_register_runstate_memory_area is an example of this.
>

Thanks for pointing out. However I still didn't understand why this 
becomes the benefit of the existing approach. For a normal parameter
conversion, the steps can be:

a) check pointer validity upon compat address limitation
b) allocate native structure with content translated from compat version
c) gear to native handler which checks native address limitation
d) back update compat structure if possible

Existing approach allocates native structure in guest address space
at step b) to bypass address check in step c), while my suggestion
is to allocate native version in Xen space by temporarily improving
address limitation at step b). You can see in either approach where
all necessary checks at step a) have to be done correctly before steping
next. For example, where partly copy applies can always be achieved
even when rest part is copied into Xen space (mixed with guest handle
but validated at step a)). Also 64bit pointer has to be checked at step a)
before improving address limitation.

Well, I'm not against existing approach since I didn't find obvious cons
to not use it. :-) As I said earlier, the intent is to get more backgrounds
and make this compat slim clearer to me. BTW, is it possible to let
guest register such compat page within its own address space? This
can release Xen overhead from managing this extra range...

Thanks,
Kevin

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