Unnecessary cache-line flush on page table updates ?

[Catalin Marinas]

On Tue, Jul 05, 2011 at 03:15:10PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 05, 2011 at 02:54:24PM +0100, Catalin Marinas wrote:
> > On Tue, Jul 05, 2011 at 11:48:58AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Jul 05, 2011 at 10:26:00AM +0100, Catalin Marinas wrote:
> > > > AFAIK the branch predictor is transparent on Cortex-A9 and the BTB
> > > > maintenance are no-ops. You wouldn't notice any issues if you remove
> > > > them (you can check ID_MMFR1[31:28].
> > > 
> > > It's not transparent:
> > > 
> > > CPU: MMFR0=0x00100103 MMFR1=0x20000000 MMFR2=0x01230000 MMFR3=0x00102111
> > > 
> > > 0b0010 Branch predictor requires flushing on:
> > > 	• enabling or disabling the MMU
> > > 	• writing new data to instruction locations
> > > 	• writing new mappings to the translation tables
> > > 	• any change to the TTBR0, TTBR1, or TTBCR registers without a
> > > 	  corresponding change to the FCSE ProcessID or ContextID.
> > 
> > OK, it makes sense. But what's really confusing - the A8 has the same
> > value for ID_MMFR1 (according to the TRM) but the BTB instructions are
> > no-ops (can can be enabled by the ACTLR.IBE bit). I suspect the ID_MMFR1
> > is wrong in this case.
> 
> Grumble.  This kind of thing worries me.
> 
> If the ID registers are wrong, then they can't be relied upon by software
> making decisions about what can be skipped.  

It could be because the BTB operations are configurable via an ACTLR
bit, but the ID registers are fixed values.

> So how can we be confident
> that MMFR3 23:20 != 0 really does mean that we don't need to clean the
> cache when writing the page tables, and is not a result of some bug?

Well, you can get other bugs, you can never guarantee anything. But when
they are found, there are errata workarounds. This would actually be a
very easy to detect issue.

-- 
Catalin