Messages in this thread | | | Date | Sat, 17 Mar 2007 01:10:18 -0800 | From | Zachary Amsden <> | Subject | Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable |
| |
Jeremy Fitzhardinge wrote: > I think the suggestion is much simpler. If you convince gcc/binutils to > leave the .reloc section in vmlinux, and make that available to the > kernel itself, then you can scan all the kernel's relocs to find ones > which refer to paravirt_ops, and use those to determine which are > callsites that can be patched. >
Yes, that is pretty nice.
> The main upside is that all the callsites are just normal C calls; > there's no special syntax or strange macros, and we get the full benefit > of typechecking, etc. > > But I can see a few downsides compared the current scheme: > > 1. Identifying the callsites is a somewhat hackish process of looking > at a reloc and doing a bit of dissassembly to see what is using > the reloc, to identify calls and jumps > 2. There's nothing explicit to tell us how much space there is to > patch into; we just have to assume sizeof(indirect call/jmp) > 3. There's no information about the register environment at the > callsite, so we just have to adopt normal C ABI rules. For the > patch sites in hand-written asm, this could be tricky. > 4. gcc could do strange things which prevent detection of patch > sites. For example, it might CSE the value of, say, > paravirt_ops.irq_enable, which would be a reasonable optimisation, > but prevent any of the resulting indirect calls from being > patched. In general it relies on gcc to generate identifiable > callsites, which is a bit unpredictable. > 5. There's still a moderate amount of binutils hackery to get the > relocs into the right form, and there's plenty of scope for it to > screw up. >
And yes, those are nasty points. I think I'd be interested in seeing more discussion on it, perhaps those issues could be worked out.
>> [ Roswell technology deleted ] >>
Nack. Everyone needs Roswell technology.
Actually, that was not a serious proposal. I think the effort and complexity would likely not justify the gain. But I still had to throw it out, since it is what we use on Betelgeuse.
Z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |