07 Dec, 2006

2 commits

  • It turns out that the most called ops, by several orders of magnitude,
    are the interrupt manipulation ops. These are obvious candidates for
    patching, so mark them up and create infrastructure for it.

    The method used is that the ops structure has a patch function, which
    is called for each place which needs to be patched: this returns a
    number of instructions (the rest are NOP-padded).

    Usually we can spare a register (%eax) for the binary patched code to
    use, but in a couple of critical places in entry.S we can't: we make
    the clobbers explicit at the call site, and manually clobber the
    allowed registers in debug mode as an extra check.

    And:

    Don't abuse CONFIG_DEBUG_KERNEL, add CONFIG_DEBUG_PARAVIRT.

    And:

    AK: Fix warnings in x86-64 alternative.c build

    And:

    AK: Fix compilation with defconfig

    And:

    ^From: Andrew Morton

    Some binutlises still like to emit references to __stop_parainstructions and
    __start_parainstructions.

    And:

    AK: Fix warnings about unused variables when PARAVIRT is disabled.

    Signed-off-by: Rusty Russell
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Chris Wright
    Signed-off-by: Zachary Amsden
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton

    Rusty Russell
     
  • Create a paravirt.h header for all the critical operations which need to be
    replaced with hypervisor calls, and include that instead of defining native
    operations, when CONFIG_PARAVIRT.

    This patch does the dumbest possible replacement of paravirtualized
    instructions: calls through a "paravirt_ops" structure. Currently these are
    function implementations of native hardware: hypervisors will override the ops
    structure with their own variants.

    All the pv-ops functions are declared "fastcall" so that a specific
    register-based ABI is used, to make inlining assember easier.

    And:

    +From: Andy Whitcroft

    The paravirt ops introduce a 'weak' attribute onto memory_setup().
    Code ordering leads to the following warnings on x86:

    arch/i386/kernel/setup.c:651: warning: weak declaration of
    `memory_setup' after first use results in unspecified behavior

    Move memory_setup() to avoid this.

    Signed-off-by: Rusty Russell
    Signed-off-by: Chris Wright
    Signed-off-by: Andi Kleen
    Cc: Jeremy Fitzhardinge
    Cc: Zachary Amsden
    Signed-off-by: Andrew Morton
    Signed-off-by: Andy Whitcroft

    Rusty Russell
     

04 Jul, 2006

2 commits