Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

2016-08-01 Thread Daniel Bolgheroni
On Mon, Aug 01, 2016 at 10:19:17PM -0300, Daniel Bolgheroni wrote: > On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > > So the CPU might speculatively load TLB entries. The upshot from this > > is that we always have to perform a TLB flush if we modify a valid > > entry. So we can

Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

2016-08-01 Thread Daniel Bolgheroni
On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > So the CPU might speculatively load TLB entries. The upshot from this > is that we always have to perform a TLB flush if we modify a valid > entry. So we can't rely on PV_BEEN_REFD() to decide whether we should > flush or not. The

Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

2016-07-31 Thread Daniel Bolgheroni
On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > So the CPU might speculatively load TLB entries. The upshot from this > is that we always have to perform a TLB flush if we modify a valid > entry. So we can't rely on PV_BEEN_REFD() to decide whether we should > flush or not. The

Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)

2016-07-31 Thread Juan Francisco Cantero Hurtado
The patch doesn't fix the bug on Cortex A7. cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache Scanning scsi 0:1... reading /sun7i-a20-olinuxino-lime2.dtb 2989

armv7 pmap fix for Cortex A53 (and Cortex A7?)

2016-07-31 Thread Mark Kettenis
The ARMv7 ARM says in B3.9 that The architecture guarantees that a translation table entry that generates a Translation fault or an Access flag fault is not held in the TLB. However a translation table entry that generates a Domain fault or a Permission fault might be held in the TLB. and