RE: [Xen-ia64-devel] Re: [Xen-devel] XenLinux/IA64 domU forward port

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

I agree with your catagory, but I think #C is the 1st challenge  we 
need to address for now. #A could be a future task for performance
 later after pv_ops functionality is completed. I don't worry about
 those several cycles difference in the primitive ops right now,
 since we already spend 500-1000 cycles to enter the C code.

The major challenge to #C is listed in my previous thread, it is not
an easy thing to address for now, especially if we need to change
original IVT code a lot.

Another big challenge is machine vector. I would like to create a
seperate
thread to discuss it some time later. Basically it has something overlap
with pv_ops. 

>> We can't destroy non bank0 register in interrupt/exception handler
>> before memory based storage is involved to save/restore them.
>> That is why I'd like to limit those parameters to bank0 registers.
>> For current Xen, it is using kind of C ABI (i.e. R8/R9), we can argu
>> if it is best, but should be easy to commodate both.
> 
> This discussion is for category C binary patching.
> At this moment I'm not sure if it can be done performance effectively.
> If the upstream requires it we can go for it, off course.

If pv_ops is there, Xen can be easily changed to do this, for example
pv_ops_init can tell hypervisor it is on pv_ops, hypervisor can then 
adopt the new ABI. For now, we can simply do that in hypervisor 
wrapper (i.e. switch to R8/R9 in the wrapper).

I didn't get a concret proposal yet, just share what I have so far, 
where I suggest to do staged approach to make the turn over 
as early as possible. See the attachment pls.

thx, eddie

Attachment: paravirt_ops2.pdf
Description: paravirt_ops2.pdf

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