LKML Archive on
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <>
To: Alan Cox <>
Cc: <>, <>,
Subject: Re: [PATCH] change name of rep_nop
Date: Tue, 9 Oct 2001 12:33:56 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>
In-Reply-To: <>

>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

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...
  some asm code specific to the presence
  or absence of a CPU feature bit

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.


  parent reply	other threads:[~2001-10-09 10:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-05 10:46 Paul Mackerras
2001-10-05 14:37 ` Alan Cox
2001-10-05 18:06   ` Peter Rival
2001-10-05 23:28   ` Paul Mackerras
2001-10-05 23:54     ` Martin J. Bligh
2001-10-06  1:40     ` Paul Mackerras
2001-10-08 19:27       ` Peter Rival
2001-10-08 22:36       ` David Woodhouse
2001-10-08 22:49         ` Alan Cox
2001-10-08 23:06         ` David Woodhouse
2001-10-08 23:42           ` David Woodhouse
2001-10-08 23:46           ` David S. Miller
2001-10-08 23:08         ` David S. Miller
2001-10-08 23:46         ` Linus Torvalds
2001-10-09  0:03           ` David Woodhouse
2001-10-08 22:46       ` David S. Miller
2001-10-08 23:16         ` Alan Cox
2001-10-08 23:24           ` Dave Jones
2001-10-08 23:33             ` Alan Cox
2001-10-09  5:01             ` George Greer
2001-10-08 23:30           ` David S. Miller
2001-10-09 10:33           ` Benjamin Herrenschmidt [this message]
2001-10-09 11:30             ` Keith Owens
2001-10-09 12:13               ` Benjamin Herrenschmidt
2001-10-09 12:15               ` Alan Cox
2001-10-09  8:51 Etienne Lorrain
2001-10-09 11:30 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] change name of rep_nop' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).