Tony & all:
Recently we have completed the IVT.s pv_ops by using dual
compile, and also many cleanups to simplify the changes to upstream
code. All the C code touching privilege instruction is replaced with
indirect function call (will be binary patched to use direct function
call in future), and IVT table is dual compiled to minimize impact to
native IVT table, but we get some dilemma in handling kernel/entry.S and
also generic policy for other ASM files.

In entry.S, there are around 17 privilege instructions, some of
them must be paravirtualized including 2 cover instructions, and 1 "RFI"
(this one is due to Xen hypervisor issue). There are other 15 privilege
instructions (In Xen) such as CR access that could be paravirtualized
for performance reason.

Now we have 2 choices:
Alt1:  Dual compile entry.S like IVT.s (dual compile all ASM
files if it needs virtualization)
pros: Same policy with iVT, use same MACRO to
replacement.
cons: There are other ASM files such as
sn/kernel/pio_phys.S need to be dual compiled too.
And unlike IVT table, the memory occupied by
dual compiled code won't be able to be freed easily since the size is
not fixed. Also all future ASM code touch privilege instruction may need
to be dual compiled too.

Alt2: Use indirect call like C code for non IVT nor gate page
code (dual compile only for IVT & gate page which has fixed size and
performance killer)
Pros: flexible for future ASM code (just use same MACRO,
no dual compile requirement).
Cons: 2 sets of solution for ASM code, and also slightly
performance lose due to indirect function call (future patching will
convert it to direct function call, or in place code.)


Any suggestions?

Thanks, eddie
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger...
More majordomo info at  http://vger.kernel.org/majordomo-info.html