[PATCH 1/2] arm64: Reduce add_map() complexity

[Oliver Graute]

On 01/08/23, Oliver Graute wrote:
> On 14/02/23, Ying-Chun Liu (PaulLiu) wrote:
> > From: Marc Zyngier <maz at kernel.org>
> > 
> > In the add_map() function, for each level it populates, it iterates from
> > the root of the PT tree, making it ineficient if a mapping needs to occur
> > past level 1.
> > 
> > Instead, replace it with a recursive (and much simpler) algorithm
> > that keeps the complexity as low as possible. With this, mapping
> > 512GB at level 2 goes from several seconds down to not measurable
> > on an A55 machine.
> > 
> > We keep the block mappings at level 1 for now though.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > Signed-off-by: Pierre-Clément Tosi <ptosi at google.com>
> > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the
> >   upstream ]
> > Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu at linaro.org>
> > Cc: Tom Rini <trini at konsulko.com>
> > Link: https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6
> > Link: https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059
> 
> Hello Marc,
> 
> this patch somehow broke the boot of my imx8qm board. I run into this
> issue:
> 
> U-Boot 2023.07-rc6-00004-g5527698481 (Aug 01 2023 - 10:10:52 +0200)
> 
> Model: Advantech iMX8QM DMSSE20
> Board: DMS-SE20A1 8GB
> Build: SCFW 549b1e18, SECO-FW c9de51c0, ATF 5782363
> Boot:  USB
> DRAM:  8 GiB
> "Error" handler, esr 0xbf000000
> elr: 0000000080020938 lr : 00000000800209c8 (reloc)
> elr: 00000000ffecf938 lr : 00000000ffecf9c8
> x0 : 0000000000000001 x1 : 0000000060000000
> x2 : 0000000010000000 x3 : 0000000000000002
> x4 : 0000000040000000 x5 : 0060000000000401
> x6 : 0000000000000800 x7 : 00000000fff44a60
> x8 : 0068000000000481 x9 : 0000000000000008
> x10: 000000000a200023 x11: 0000000000000002
> x12: 0000000000000002 x13: 0000000080095a00
> x14: 00000000ffffffff x15: 00000000ffecfd2c
> x16: 000000008005454c x17: 0000000000000000
> x18: 00000000fd6afd50 x19: 000000000fe00000
> x20: 0000000000000000 x21: 0060000000000401
> x22: 0000000060200000 x23: 0000000000200000
> x24: 0000000040000808 x25: 00000000001fffff
> x26: 0000000000000003 x27: 0000000060200000
> x28: 0000000000000002 x29: 00000000fd6ab110
> 
> Code: a94573fb a8c67bfd d65f03c0 b9418a40 (8a160334)
> Resetting CPU ...
> 
> resetting ...
> SCI reboot request............................................................................................................................................................................................................................
> 
> After some bisecting this patch poped up: 
> 
> 41e2787f5ec4249cb2e77a3ebd3c49035e3c6535 is the first bad commit
> arm64: Reduce add_map() complexity
> 
> After I reverted everything on top of this patch its booting again with v2023.07
> 
> commit c1da6fdb5c239b432440721772d993e63cfdeb20
> armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present
> 
> commit 836b8d4b205d2175b57cb9ef271e638b0c116e89
> arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present
> 
> commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213
> arm64: Use FEAT_HAFDBS to track dirty pages when available
> 
> 
> Do you have any idea whats going on here?

Is this behavior somehow releated to the known Cache coherency issue on
A53 Core on NXP imx8qm?

https://lore.kernel.org/linux-arm-kernel/ZDflS%2FCnEx8iCspk@FVFF77S0Q05N/T/#mf733406e618244b0b21fd25077febd69b31b686e

+Jason Liu
+Peng Fan

Best Regards,

Oliver