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
paravirt_ops2.pdf
Description: paravirt_ops2.pdf
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home