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

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Tue, Feb 05, 2008 at 07:41:05AM +0800, Dong, Eddie wrote:
> 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 :)

Actually already we adopted dual compilatin approach for gate page.
See gate.S in xenLinux arch/ia64/kernel/gate.S and Makefile.
I'm guessing that dual compiling approach is easier than binary
patching approach because some modification of xenivt.S doesn't 
correspond to single instruction.
Yes I agree that we can go for either way according to upstream favor.


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

With respect to hypervisor ABI, we have already differentiate them.
ia64 specific HYPERVIRVOPS as static registers convention and
normal xen hypercall as stacked registers convention.


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

I'm guessing one important exception is masking/unmasking interrupts.
i.e. ssm/rsm psr.i. Anyway we will see during our merge effort.

-- 
yamahata

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