lkml.org 
[lkml]   [2007]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
    Date
    Rusty Russell <rusty@rustcorp.com.au> writes:

    > On Sun, 2007-03-18 at 13:08 +0100, Andi Kleen wrote:
    >> > The idea is _NOT_ that you go look for references to the paravirt_ops
    >> > members structure, that would be stupid and you wouldn't be able to
    >> > use the most efficient addressing mode on a given cpu, you'd be
    >> > patching up indirect calls and crap like that. Just say no...
    >>
    >> That wouldn't handle inlines though. At least some of the current
    >> paravirtops like cli/sti are critical enough to require inlining.
    >
    > Well, we'd patch the inline over the call if we have room.
    >
    > Magic patching would be neat, but the downsides are that (1) we can't
    > expand the patching room and (2) there's no way of attaching clobber
    > info to the call site (doing register liveness analysis is not
    > appealing).

    True. You can use all of the call clobbered registers.

    > Now, this may not be fatal. 5 bytes is enough for all the native ops to
    > be patched inline. For lguest this covers popf and pushf, but not cli
    > and sti (10 bytes): they'd have to be calls.
    >
    > As for clobber info, it turns out that almost all of the calls can
    > clobber %eax, which is probably enough. We just need to mark the
    > handful of asm ones where this isn't true.

    I guess if the code is larger than a function call I'm failing to see
    the disadvantage in making it a direct function call. Any modern
    processor ought to be able to predict it perfectly, and processors
    like the P4 may even optimize the call out of their L1 instruction
    cache.

    If what David is suggesting works, making all of these direct calls
    looks easy and very maintainable. At which point patching
    instructions inline is quite possibly overkill.

    Is it truly critical to inline any of these instructions?

    Eric
    -
    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-19 19:31    [W:2.291 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site