On Sat, 21 Oct 2023, 2:04 am Marc Zyngier, maz@kernel.org wrote:
On 2023-10-18 21:53, Chris Packham wrote:
Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages when available") the default get_page_table_size() sets some flags for more efficient handling of dirty page table entries. This causes problems on the AC5/AC5X SoC (specifically a lockup when calling __asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
The reason for the lockup isn't at all clear but it can be avoided if we provide our own get_page_table_size() which stops gd->arch.has_hafdbs from being set to true effectively returning the AC5/AC5X to the older behaviour. This also opts for a simple fixed page table size rather than trying to duplicate the more complicated logic to optimise the table size.
Signed-off-by: Chris Packham judge.packham@gmail.com
arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c b/arch/arm/mach-mvebu/alleycat5/cpu.c index 8204d9627515..7ba57ae75e76 100644 --- a/arch/arm/mach-mvebu/alleycat5/cpu.c +++ b/arch/arm/mach-mvebu/alleycat5/cpu.c @@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
struct mm_region *mem_map = ac5_mem_map;
+u64 get_page_table_size(void) +{
return 0x80000;+}
void reset_cpu(void) { }
This looks terribly wrong. In all honesty, if the original patch creates problems and that people add this sort of stuff to paper over it, I'd rather your *revert* my patch altogether.
There are other platforms that define a get_page_table_size(). That may mean that they are just inadvertently avoiding the issues I'm seeing.
I'm happy to prepare a series reverting the problematic changes. But I'm sure that there's something about the AC5 that's the actual problem. I'm just out of my depth in terms of my ability to progress it.
M.-- Jazz is not dead. It just smells funny...