lkml.org 
[lkml]   [2001]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] change name of rep_nop
    Date
    >That raises the question of whether x86 should seperate the "386" "486" ..
    >kernels by adding "Generic" for building a kernel that has all the work
    >arounds for everyones randomly buggy processors

    One approach we take on PPC that you may or may not like for this is
    dynamic patching.

    Basically, we have some very early init code that probes the CPU type,
    and extract from a table a bit mask of "CPU features". Those can be
    real features, like has an FPU or an Altivec, but can also be known
    erratas.

    Then, we have a a couple of macros that look like this : (to be used
    in .S files or in inline assembly)

    some asm code...
    BEGIN_FEATURE_SECTION()
    some asm code specific to the presence
    or absence of a CPU feature bit
    END_FEATURE_SECTION(mask, value)

    basically, what those macros do is to add references to the enclosed
    bit of code to a separate ELF section, along with the mask & values
    32 bit values.

    The early CPU probe code, after having determined the feature bits mask
    of the CPU will then walk that additional ELF section, and for each
    entry in it (an entry is a start address, an end address, a mask and
    a value), will test if (cpu_feature & mask) == value. If the result is
    false, then the entire section of code referenced is replaced with nop's.

    This works well for small bits of code (we use it for commenting out
    some altivec code in the context switch path on non-altivec machines,
    and for nop'ing out some "sync" intructions that are only necessary
    on some older buggy CPUs). You still have the cost of executing a NOP
    (which is pretty minimal on PPC, but other archs may want a more suitable
    instruction as NOP can be context synchronising on some CPUs).

    If you happen to have large code sections covered by this mecanism,
    the patching code can be improved to insert a branch to the end of
    the nop'ed out section on it's first instruction.

    Regards,
    Ben.


    -
    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: 2005-03-22 13:17    [W:4.144 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site