[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6bd09b5b-9830-42b4-ad9e-9ad1e153e564@arm.com>
Date: Tue, 5 Aug 2025 16:08:24 +0100
From: Ada Couprie Diaz <ada.coupriediaz@....com>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: Ada Couprie Diaz <ada.coupriediaz@....com>, catalin.marinas@....com,
will@...nel.org, oleg@...hat.com, sstabellini@...nel.org,
mark.rutland@....com, puranjay@...nel.org, broonie@...nel.org,
mbenes@...e.cz, ryan.roberts@....com, akpm@...ux-foundation.org,
chenl311@...natelecom.cn, anshuman.khandual@....com,
kristina.martsenko@....com, liaochang1@...wei.com, ardb@...nel.org,
leitao@...ian.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH -next v7 0/7] arm64: entry: Convert to generic irq entry
Hi Jinjie,
On 29/07/2025 02:54, Jinjie Ruan wrote:
> Since commit a70e9f647f50 ("entry: Split generic entry into generic
> exception and syscall entry") split the generic entry into generic irq
> entry and generic syscall entry, it is time to convert arm64 to use
> the generic irq entry. And ARM64 will be completely converted to generic
> entry in the upcoming patch series.
Note : I had to manually cherry-pick a70e9f647f50 when pulling the series
on top of the Linux Arm Kernel for-next/core branch, but there might be
something I'm missing here.
>
> The main convert steps are as follows:
> - Split generic entry into generic irq entry and generic syscall to
> make the single patch more concentrated in switching to one thing.
> - Make arm64 easier to use irqentry_enter/exit().
> - Make arm64 closer to the PREEMPT_DYNAMIC code of generic entry.
> - Switch to generic irq entry.
I reviewed the whole series and as expected it looks good ! Just a few nits
here and there and some clarifications that I think could be useful.
I'm not sure about the generic implementation of
`arch_irqentry_exit_need_resched()`
in patch 5, I would be tempted to move it to patch 7. I detail my
thoughts more
on the relevant patches, but I might be wrong and that feels like details :
I don't think the code itself has issues.
> It was tested ok with following test cases on QEMU virt platform:
> - Perf tests.
> - Different `dynamic preempt` mode switch.
> - Pseudo NMI tests.
> - Stress-ng CPU stress test.
> - MTE test case in Documentation/arch/arm64/memory-tagging-extension.rst
> and all test cases in tools/testing/selftests/arm64/mte/*.
>
> The test QEMU configuration is as follows:
>
> qemu-system-aarch64 \
> -M virt,gic-version=3,virtualization=on,mte=on \
> -cpu max,pauth-impdef=on \
> -kernel Image \
> -smp 8,sockets=1,cores=4,threads=2 \
> -m 512m \
> -nographic \
> -no-reboot \
> -device virtio-rng-pci \
> -append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> earlycon preempt=voluntary irqchip.gicv3_pseudo_nmi=1" \
> -drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> -device virtio-blk-device,drive=hd0 \
>
I'll spend some time testing the series now, specifically given patch 6's
changes, but other than that everything I saw made sense and didn't look
like it would be of concern to me.
Thanks,
Ada
Powered by blists - more mailing lists