shared memory problem on ARM v5TE using threads

[Russell King - ARM Linux]

On Mon, Dec 07, 2009 at 02:52:35PM +0000, Russell King - ARM Linux wrote:
> On Mon, Dec 07, 2009 at 02:55:52PM +0200, Ronen Shitrit wrote:
> > That also match the theory:
> > When using different processes, the shared area will stay C=1 B=1, 
> > On each context switch L1 will be flushed,
> > Since L2 is PIPT next process will get the correct data...
> 
> Hang on - if L2 is PIPT, then there shouldn't be a problem provided it's
> searched with C=0 B=1 mappings.  Is that the case?

Officially, ARMv5 does not support the 'extended small page' format for
the 2nd level descriptors (ARMv6 and Xscale CPUs added this support.)

That means ARMv5 officially only has support for two bits to control
the caching attributes - the C and B bits.  This means we can't specify
the policy for the L2 cache... unless Feroceon also supports the
'extended small page' format.  This might be a third solution to the
problem, and probably the best - provided Feroceon will allow us to
specify 'inner non-cacheable outer write-back' (TEX=111 CB=00).

If Feroceon did support the 'extended small page' format, why isn't it
already using this?  (It's setup to use the architecturally defined
'small page' format for ARMv3 to ARMv5.)