Hi Eddie.
On Thu, Feb 14, 2008 at 04:17:05PM +0800, Dong, Eddie wrote:
> > Eddie, I haven't forgotten your discussion.
> > I think it is necessary to get linux-ia64 people involved for
> > the discussion. The concrete patch is needed.
>
> Yes, so are you planing to push pv_ops based solution or
> binary patching based solution? My basic understanding to
> redhat's concern is that they want to adopt similar approach
> in IA64 side together with X86, which uses pv_ops.
>From my understandings, x86 pv_ops are categorized as three parts.
A. C code: Performance critical
Basically indirect function call via pv_xxx_ops.
For performance, each pv instance is allowed binary patch
in order to replace calling instruction with their predefined
instructions.
B. C code: Not performance critical
The indirect function call vi pv_xxx_ops. But binary patching isn't
allowed. (or it's unnecessary.)
C. ASM code with binary patching
Some macros for hand written assembly code.
Its indirect function call allowing binary patching.
What I implemented in this patch corresponds to A.
It is already similar to x86 pv_ops ones.
(At least I think so. Please complain unless you agree.)
Please see following files.
- linux/include/asm-ia64/paravirt_alt.h
- linux/include/asm-ia64/privop_paravirt.h
Although function call table isn't defined, it is allowed to
replace instructions with branch instruction.
For category B, the IA64 counter part would be also indirect call.
But I'm not sure it would have ia64 pv_ops or be included into
ia64 machine vector. It doesn't matter as long as the upstream
maintainer likes it.
I expect the function set would be developed during clean up/merge.
For category C, we haven't addressed it yet. This is the issue.
What we are doing currently is just maintaining manually
paravirtualized code and changing execution path. And this execution
path changing can be done relatively cleanly with binary patching.
So far some ways have been proposed:
The current way, dual compiling and binary patching.
They have their own pros and cons. Anyway I want to discuss with
linux-ia64 people before starting implementation.
> > Once I split the patch up, I'll post them to linux-ia64 so that we
> > can start the discussion with them.
> > My vague idea is as follows.
> > - For neutral paravirtualization api, some kind of ABI is necessary.
> > - It would need some kind of static calling convention.
> > - Currently the nearest standard is PAL static calling convention.
> > So far I agree with you.
> > - PAL static calling convention uses banked registers(r16-r31) as
> > arguments. However it would be suboptimal or unsuitable for
> > paravirtualization ABI. Static and non-banked registers are
> > desirable.(at least for Xen) so that r9-r11, r14-r15 are desirable.
>
> 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.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home