WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

Isaku Yamahata wrote:
> Oh, I misunderstood your patch.
> I thought it just revert entry.S to original state. But it
> paravirtualized conver and rfi with running_on_xen check.
> Now I'm convinced that your patch works. Only one comment on
> the patch itself is,
> #ifdef CONFIG_XEN is necessary for !CONFIG_XEN case.
> 
> 
> Then the left issue is 'if the patch is acceptable for the upstream'.
> The purpose of reducing the total patch size is eventually
> to make ia64/xen domU patches more acceptable for the upstream.
> However with the patch you reintroduced running_on_xen check which
> we have eliminted. That contradicts with the pv_ops principle.
> It's a trade off between the patch size and the patch cleanness.

That is a temporary solution, I am working to use indirect function
call.

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

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

Eddie

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