Re: [Xen-ia64-devel] pv_ops: entry.S simplification

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Fri, Mar 28, 2008 at 01:43:23PM +0800, Dong, Eddie wrote:

> > Eventually those running_on_xen checks should be removed somehow.
> > Are you just thinking that the multi compile with binary patching
> > should be introduced after the first merge?
> > Or do you have any idea other than the multi compile with binary
> > patching? 
> > 
> 
> Dual compile every change may be not necessary for me.
> The reason for IVT is that code there is very critical and stakeholders
> won't change them to steal registers. They even don't want a single
> change without full hand of performance data + stress test.
> 
> In entry.S, steal clobber register is easy.

ia64_swtich_to(), ia64_leave_syscall() and ia64_leave_kernel()
are also performance critical, aren't they?


> > Anyway it's linux-ia64 people that finally determines what way is
> > better. To be honest I'm not sure which way is more acceptable.
> > So let's discuss with linux-ia64.
> > 
> > 
> Yes, we can, but keeping that big patch is a problem for now.
> Also the switch_entry.S has a "ugly" code that must use binary patching
> to patch to Xen.
> 
> Meanwhile like you mentioned yesterday, where to do binary patching 
> is an issue, especially for native case. Current approach doesn;t
> consider
> native patching which is more important than xen patching for now.

What's your cope?
I thought binary patching for optimization is for the next domU
optimization phase after the first merge phase so that I've dropped
binary patching code from domU minimal tree (there still remans some
code related to entry.S though) and introduced pv_cpu_ops with
C indirect function call.
However introducing pv_init_ops.patch now condradicts with those
effort.
-- 
yamahata

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