lkml.org 
[lkml]   [2007]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-03-17 10:13    [W:3.370 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site