lkml.org 
[lkml]   [2007]   [Mar]   [16]   [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

    * David Miller <davem@davemloft.net> wrote:

    > From: Ingo Molnar <mingo@elte.hu>
    > Date: Fri, 16 Mar 2007 10:24:45 +0100
    >
    > > ugh. This is beyond ugly! Why dont we just compile two images, one
    > > for Xen and one for native, do two passes to get those two images
    > > and 'merge' them into a single vmlinuz (so that we still have a
    > > 'single' kernel unit to deal with on the distro side). This way we
    > > avoid all this crazy, limited, fragile patchery business...
    >
    > Perhaps the problem can be dealt with using ELF relocations.
    >
    > There is another case, discussed yesterday on netdev, where run-time
    > resolution of ELF relocations would be useful (for
    > very-very-very-read-only variables) so if it can solve this problem
    > too it would be nice to have a generic infrastructure for it.

    yeah, and i really think this is very fundamental: we've already got a
    very nice tool that can do things like detect when we are paravirt and
    optimize and patch things in a machine-specific way. It can even reorder
    instructions and simulate the CPU's pipeline state and do very smart
    optimizations based on that. It's a really neat thing, they call it
    "GCC".

    Limited, instruction-level patching like alternatives.h is fine because
    that makes it easier to support multiple, incompatible CPU
    architectures, without having to do a hugely intrusive split at the
    kernel RPM level.

    but the level of 'binary patching' done by the paravirt and Xen goes way
    beyond that, and the changes here really underscore that we:

    _should not emulate the closed source world_

    There the only solution is to binary-patch - because they have no source
    code. But here, we've got all the source code.

    splitting the images and simply extending vmlinuz to have a
    'multi-image' format would not only eliminate a huge amount of hookery,
    it would also solve the problem of CONFIG_PARAVIRT bloating the native
    kernel's codepaths by ~7%.

    nobody wants to boot a xen-paravirt kernel from a floppy, so image size
    is not an issue. In-RAM overhead would in fact be /reduced/, because
    currently all the paravirt overhead hits both the native and the
    paravirt kernel. Nor would /all/ of the vmlinuz have to be replicated in
    the images - it's enough to replicate only those functions that truly
    differ between the two build methods.

    Ingo
    -
    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-16 11:01    [W:5.625 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site