[U-Boot] [PATCH] 8313erdb: Set guarded bit on BAT that covers the end of the address space.

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 17 March 2009 14:18:13 Scott Wood wrote:
> Mike Frysinger wrote:
> >>> if C code is doing ptr checks, the compiler should make sure that
> >>> pointer is not dereferenced at all if the hardware cannot suffer the
> >>> consequences, even speculatively.
> >>
> >> There is no reasonable way for the compiler to prevent such speculative
> >> accesses.  Non-memory-like mappings must have the guarded bit set.  That
> >> is what the bit is there for.
> >
> > if the hardware doesnt have a way of preventing it, then the compiler
> > must nop bad accesses that are unknown.
>
> The hardware *does* have a way of preventing it.  It's the guarded bit. :-)
>
> I don't know of any amount of "nop" instructions that would be
> architecturally guaranteed to avoid this -- they're no-ops, not syncs
> (despite how some other architectures use them).  They can be discarded
> as fast as the chip can decode them.

right, it depends on the pipeline.  some let the nops force the address decode 
stages to get filled so they dont get speculatively filled and then fetched.  
sounds like the ppc pipeline doesnt operate that way.

> Adding an isync instruction should avoid it, but that's a heavy
> performance penalty.  Why pay it for all accesses rather than just those
> which are not memory-like (and can be flagged as such in the TLB)?

right, if the mappings allow speculative fetches to be turned off for certain 
regions, that's the way to go

> > i'm not sure your example proves your position.  if you have a region
> > that cannot stand speculative access, how do you handle bad pointer
> > checking if the compiler may generate code that'll speculatively hit it
> > at any time ?
>
> The compiler is not speculatively doing anything.  It is the CPU -- and
> the guarded bit tells it to not do that.

i didnt mean the compiler was doing it.  i meant the compiler generates dense 
code that the hardware turns around and speculatively loads.

the change sounded like you were addressing a specific issue that was noticed, 
but other regions could still (in general) cause problems.  but i guess that 
isnt the case at all.

thanks for the info
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090317/339e2fbf/attachment.pgp