Re: [PATCH v15 00/11] arm64: entry: Convert to Generic Entry

[Ada Couprie Diaz <ada.coupriediaz@arm.com>]

Hi Jinjie,

On 11/05/2026 10:20, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> maintainers' work easier and codes more elegant. arm64 has already
> successfully switched to the Generic IRQ Entry in commit
> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> time to completely convert arm64 to Generic Entry.
>
> [...]
>
> It was tested ok with following test cases on QEMU virt platform:
>   - Stress-ng CPU stress test.
>   - Hackbench stress test.
>   - "sud" selftest testcase.
>   - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
>     in tools/testing/selftests/ptrace.
>   - breakpoint_test_arm64 in selftests/breakpoints.
>   - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
>   - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
>   - vdso_test_getrandom in tools/testing/selftests/vDSO
>   - Strace tests.
>
> The test QEMU configuration is as follows:
>
> 	qemu-system-aarch64 \
> 		-M virt \
> 		-enable-kvm \
> 		-cpu host \
> 		-kernel Image \
> 		-smp 8 \
> 		-m 512m \
> 		-nographic \
> 		-no-reboot \
> 		-device virtio-rng-pci \
> 		-append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> 			earlycon irqchip.gicv3_pseudo_nmi=1" \
> 		-drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> 		-device virtio-blk-device,drive=hd0 \

Thanks for the series and the extensive test coverage !

I did some additional testing on my side with the series rebased
on -rc5, to get the latest fixes from Mark Rutland, focusing on stability
rather than performance, with the following configurations :

- Systems
   - M1SDP (4 CPU, 16 GiB RAM, GICv3)
   - QEMU/KVM on M1SDP (4 CPU, 4 GiB RAM, GICv3)
     - Host running upstream
     - Host running this series
   - AMD Seattle (4 CPU, 8 GiB RAM, GICv2)
- Kernel configurations (+ debug options[1])
   - defconfig
   - pseudo-NMI (except on Seattle)
   - PREEMPT_RT
   - PREEMPT_RT + pseudo-NMI (except on Seattle)
- Tests
   - stress-ng
     - CPU stress test
     - Interrupt stress tests
     - Virtual Memory stress tests
     - Syscall validation tests
   - Hackbench
   - pseudo-NMI load tests via perf
   - debug exception entry load tests
   - memcached stress test via mc-crusher
   - The above plus high system load/low available memory
   - Suspend test via /sys/power/pm_test
   - Hibernate (QEMU only)


All tests were able to complete without major issues !


However, when combining pseudo-NMIs with PREEMPT_RT under heavy pNMI load,
I was able to trigger a new warning compared to upstream :

     BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

Specifically, this was when running `stress-ng --all 100 --class vm -t 
300` with
`perf top -a -e 'cycles'` in another shell.

This does not feel like a major issue : from my understanding it only 
happens
when running the full suite for some time and with many stressors (I was not
able to reproduce it by running individual tests), and flooding the 
system with
pseudo-NMIs.

Given that this only happen with PREEMPT_RT, my guess is that it interacts
with generic entry in a way that can lead to more nesting than before,
leading to an easier exhaustion of the limit on lockdep.
As the system was still able to recover and did not lock up, I think it 
can be OK
as-is, or simply bumped a bit ? Happy for more opinions on that.


Otherwise, this is
Tested-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>

As this is an important change, any other testing, especially on real 
workloads
as well as on very large systems (which we haven't covered), would be 
very welcome !


I will take some time soon to review this latest version, now that I am 
able to.

Thanks again,
Kind regards
Ada

[0] BUG dump

    BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
    turning off the locking correctness validator.
    CPU: 0 UID: 0 PID: 77252 Comm: stress-ng-shm-s Tainted: G        W           7.1.0-rc5-pnmi-rt-00011-g856fda168b7e #477 PREEMPT_RT
    Tainted: [W]=WARN
    Hardware name: ARM LTD Morello System Development Platform, BIOS EDK II Mar  7 2024
    Call trace:
      show_stack+0x20/0x38 (C)
      dump_stack_lvl+0xf8/0x1b8
      dump_stack+0x18/0x28
      __lock_acquire+0x1a50/0x1f78
      lock_acquire+0x260/0x448
      _raw_spin_lock+0x50/0x70
      rcu_note_context_switch+0x11c/0x608
      __schedule+0x100/0x1280
      preempt_schedule_irq+0x58/0x158
      raw_irqentry_exit_cond_resched+0x4c/0x78
      arm64_exit_to_kernel_mode+0xa8/0x158
      el1_interrupt+0x58/0xb0
      el1h_64_irq_handler+0x18/0x28
      el1h_64_irq+0x80/0x88
      lock_acquire+0x3b0/0x448 (P)
      rt_spin_lock+0x11c/0x218
      new_inode+0x38/0x78
      __shmem_get_inode+0xa8/0x408
      __shmem_file_setup+0x16c/0x1b0
      shmem_kernel_file_setup+0x38/0x50
      newseg+0x100/0x3d8
      ipcget+0x464/0x5f0
      __arm64_sys_shmget+0x64/0xa0
      invoke_syscall.constprop.0+0x58/0x118
      do_el0_svc+0x64/0x3d8
      el0_svc+0x54/0x310
      el0t_64_sync_handler+0xa0/0xe8
      el0t_64_sync+0x1ac/0x1b0


[1] Debug options defconfig :

CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y
CONFIG_PM_DEBUG=y
CONFIG_PM_ADVANCED_DEBUG=y
CONFIG_KPROBES=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_IRQFLAGS=y
CONFIG_RCU_EQS_DEBUG=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FPROBE=y
CONFIG_USER_EVENTS=y