RE: [Xen-ia64-devel] paravirt_ops and its alternatives

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Yang, Fred wrote:
> Alex Williamson wrote:
>> On Mon, 2008-02-04 at 09:53 +0800, Dong, Eddie wrote:
>>> Yang, Fred wrote:
>>>> Dong, Eddie wrote:
>>>>> Re-post it to warmup discussion in case people can't read PPT
>>>>> format,
>>>> 
>>>> IVT is very performance sensitive for the native Linux, how about
>>>> dual IVT tables alternative for CPU virtualization?  It would need
>>>> maintainance effort but it would be much cleaner forIA64 situation.
>>>> -Fred
>>> 
>>> Dual IVT table could be a night mare for Tony, I guess. But yes we
>>> need to have more active discussion to kick it off.
>> 
>>    Yes, two separate IVTs with 95+% of the code being the same would
>> not be ideal.  I think we should aim for a single ivt.S that gets
>> compiled a couple times with different options, once for native and
>> again for each virtualization option.  It looks like more than half
>> of the changes in xenivt.S could be easily converted to macros that
>> could be switched by compile options.  Perhaps a pattern will emerge
>> for the rest.
> If it is not necessarily to stick with a single image and runtime to
> determine code path, multi-compile paths to generate different PV or
> native image then macros can possibly work.. -Fred 

Dual compile could be a good approach. Another alternative will be X86
pv_ops like dynamic binary patching per compile time hints. The later 
method also uses macro for those different path, but this macro will 
generate a special section including the information for runtime patch
base on pv_ops hook. (some kind of similar to Yamahata's binary
patch method though it addresses C side code)

With dynamic pv_ops patch, the native machine side will again see
original single instruction + some nop. So I guess the performance lose
will be very minor. Both approach is very similar and could be left
to Linux community's favorite in future :)


Another problem I want to raise is about pv_ops calling convention.
Unlike X86 where stack is mostly available, IPF ASM code such as
IVT entrance doesn't invoke stack, so I think we have to define 
static registers only pv_ops & stacked registers pv_ops like PAL.

For most ASM code (ivt), it have to use static registers only pv_ops.
We need to carefully define the clobber registers used and do 
manual modification to Linux IVT.s. Dual IVT table or binary 
patching is preferred for performance.

Stacked register pv_ops could follow C convention and it is less
performance critical, so probably no need to do dynamic patching.

more comments are welcome:)
Eddie

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