* [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX [not found] <20230702195057.1787686-1-sashal@kernel.org> @ 2023-07-02 19:50 ` Sasha Levin 2023-07-03 11:51 ` Mark Brown 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 09/12] arm64: set __exception_irq_entry with __irq_entry as a default Sasha Levin ` (2 subsequent siblings) 3 siblings, 1 reply; 13+ messages in thread From: Sasha Levin @ 2023-07-02 19:50 UTC (permalink / raw) To: linux-kernel, stable Cc: Kristina Martsenko, Catalin Marinas, Sasha Levin, will, broonie, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel From: Kristina Martsenko <kristina.martsenko@arm.com> [ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ] Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, so that subsequent patches can check for its presence. KVM currently relies on the register being present on all CPUs (or none), so the kernel will panic if that is not the case. Fortunately no such systems currently exist, but this can be revisited if they appear. Note that the kernel will not panic if CONFIG_KVM is disabled. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> Link: https://lore.kernel.org/r/20230509142235.3284028-3-kristina.martsenko@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/kernel/cpufeature.c | 8 ++++++++ arch/arm64/tools/cpucaps | 1 + 2 files changed, 9 insertions(+) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 7d7128c651614..9898ad77b1dba 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -364,6 +364,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = { static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = { ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_TIDCP1_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_AFP_SHIFT, 4, 0), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_HCX_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_ETS_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_TWED_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_XNX_SHIFT, 4, 0), @@ -2309,6 +2310,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .type = ARM64_CPUCAP_SYSTEM_FEATURE, .matches = is_kvm_protected_mode, }, + { + .desc = "HCRX_EL2 register", + .capability = ARM64_HAS_HCX, + .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE, + .matches = has_cpuid_feature, + ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HCX, IMP) + }, #endif { .desc = "Kernel page table isolation (KPTI)", diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps index 40ba95472594d..e1de10fa080e0 100644 --- a/arch/arm64/tools/cpucaps +++ b/arch/arm64/tools/cpucaps @@ -32,6 +32,7 @@ HAS_GENERIC_AUTH_IMP_DEF HAS_GIC_CPUIF_SYSREGS HAS_GIC_PRIO_MASKING HAS_GIC_PRIO_RELAXED_SYNC +HAS_HCX HAS_LDAPR HAS_LSE_ATOMICS HAS_NESTED_VIRT -- 2.39.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX Sasha Levin @ 2023-07-03 11:51 ` Mark Brown 2023-07-09 14:56 ` Sasha Levin 0 siblings, 1 reply; 13+ messages in thread From: Mark Brown @ 2023-07-03 11:51 UTC (permalink / raw) To: Sasha Levin Cc: linux-kernel, stable, Kristina Martsenko, Catalin Marinas, will, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 823 bytes --] On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote: > From: Kristina Martsenko <kristina.martsenko@arm.com> > > [ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ] > > Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, > so that subsequent patches can check for its presence. > > KVM currently relies on the register being present on all CPUs (or > none), so the kernel will panic if that is not the case. Fortunately no > such systems currently exist, but this can be revisited if they appear. > Note that the kernel will not panic if CONFIG_KVM is disabled. This is a new feature, it's not clear why we'd backport it (especially since it's a new feature which is a dependency for other features rather than something that people can use outside of the kernel)? [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-03 11:51 ` Mark Brown @ 2023-07-09 14:56 ` Sasha Levin 2023-07-09 21:13 ` Mark Brown 0 siblings, 1 reply; 13+ messages in thread From: Sasha Levin @ 2023-07-09 14:56 UTC (permalink / raw) To: Mark Brown Cc: linux-kernel, stable, Kristina Martsenko, Catalin Marinas, will, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote: >On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote: >> From: Kristina Martsenko <kristina.martsenko@arm.com> >> >> [ Upstream commit b0c756fe996ac930033882ca56410639e5cad1ec ] >> >> Detect if the system has the new HCRX_EL2 register added in ARMv8.7/9.2, >> so that subsequent patches can check for its presence. >> >> KVM currently relies on the register being present on all CPUs (or >> none), so the kernel will panic if that is not the case. Fortunately no >> such systems currently exist, but this can be revisited if they appear. >> Note that the kernel will not panic if CONFIG_KVM is disabled. > >This is a new feature, it's not clear why we'd backport it (especially >since it's a new feature which is a dependency for other features rather >than something that people can use outside of the kernel)? The second paragraph (above) suggested it should be. -- Thanks, Sasha _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-09 14:56 ` Sasha Levin @ 2023-07-09 21:13 ` Mark Brown 2023-07-10 9:44 ` Will Deacon 0 siblings, 1 reply; 13+ messages in thread From: Mark Brown @ 2023-07-09 21:13 UTC (permalink / raw) To: Sasha Levin Cc: linux-kernel, stable, Kristina Martsenko, Catalin Marinas, will, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 942 bytes --] On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote: > On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote: > > On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote: > > > KVM currently relies on the register being present on all CPUs (or > > > none), so the kernel will panic if that is not the case. Fortunately no > > > such systems currently exist, but this can be revisited if they appear. > > > Note that the kernel will not panic if CONFIG_KVM is disabled. > > This is a new feature, it's not clear why we'd backport it (especially > > since it's a new feature which is a dependency for other features rather > > than something that people can use outside of the kernel)? > The second paragraph (above) suggested it should be. That's saying that the code won't work properly on systems where some but not all of the CPUs support the feature. Note that the changelog says nothing about fixing any issue here. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-09 21:13 ` Mark Brown @ 2023-07-10 9:44 ` Will Deacon 2023-07-10 13:31 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Will Deacon @ 2023-07-10 9:44 UTC (permalink / raw) To: Mark Brown Cc: Sasha Levin, linux-kernel, stable, Kristina Martsenko, Catalin Marinas, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel On Sun, Jul 09, 2023 at 10:13:29PM +0100, Mark Brown wrote: > On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote: > > On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote: > > > On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote: > > > > > KVM currently relies on the register being present on all CPUs (or > > > > none), so the kernel will panic if that is not the case. Fortunately no > > > > such systems currently exist, but this can be revisited if they appear. > > > > Note that the kernel will not panic if CONFIG_KVM is disabled. > > > > This is a new feature, it's not clear why we'd backport it (especially > > > since it's a new feature which is a dependency for other features rather > > > than something that people can use outside of the kernel)? > > > The second paragraph (above) suggested it should be. > > That's saying that the code won't work properly on systems where some > but not all of the CPUs support the feature. Note that the changelog > says nothing about fixing any issue here. Try reading it like a GPU running an ML model: "This is not a new feature, it's especially clear why we'd backport it." Makes sense. *sigh* We've been considering opting arm64 out of this for a while, but I don't think we do a great job of CC'ing stable either (I certainly forget to add it all the time and then hope that the Fixes: tag does the job),so it's not obviously going to improve things. Maybe we just need a commit hook that yells if something with a Fixes: tag doesn't have a CC: stable on it? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-10 9:44 ` Will Deacon @ 2023-07-10 13:31 ` Greg KH 2023-07-10 13:47 ` Mark Brown 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2023-07-10 13:31 UTC (permalink / raw) To: Will Deacon Cc: Mark Brown, Sasha Levin, linux-kernel, stable, Kristina Martsenko, Catalin Marinas, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote: > On Sun, Jul 09, 2023 at 10:13:29PM +0100, Mark Brown wrote: > > On Sun, Jul 09, 2023 at 10:56:13AM -0400, Sasha Levin wrote: > > > On Mon, Jul 03, 2023 at 12:51:57PM +0100, Mark Brown wrote: > > > > On Sun, Jul 02, 2023 at 03:50:52PM -0400, Sasha Levin wrote: > > > > > > > KVM currently relies on the register being present on all CPUs (or > > > > > none), so the kernel will panic if that is not the case. Fortunately no > > > > > such systems currently exist, but this can be revisited if they appear. > > > > > Note that the kernel will not panic if CONFIG_KVM is disabled. > > > > > > This is a new feature, it's not clear why we'd backport it (especially > > > > since it's a new feature which is a dependency for other features rather > > > > than something that people can use outside of the kernel)? > > > > > The second paragraph (above) suggested it should be. > > > > That's saying that the code won't work properly on systems where some > > but not all of the CPUs support the feature. Note that the changelog > > says nothing about fixing any issue here. > > Try reading it like a GPU running an ML model: > > "This is not a new feature, it's especially clear why we'd backport it." > > Makes sense. *sigh* > > We've been considering opting arm64 out of this for a while, but I don't > think we do a great job of CC'ing stable either (I certainly forget to > add it all the time and then hope that the Fixes: tag does the job),so > it's not obviously going to improve things. > > Maybe we just need a commit hook that yells if something with a Fixes: > tag doesn't have a CC: stable on it? I could start doing that, it's going to be really noisy... greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-10 13:31 ` Greg KH @ 2023-07-10 13:47 ` Mark Brown 2023-07-10 14:09 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Mark Brown @ 2023-07-10 13:47 UTC (permalink / raw) To: Greg KH Cc: Will Deacon, Sasha Levin, linux-kernel, stable, Kristina Martsenko, Catalin Marinas, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 564 bytes --] On Mon, Jul 10, 2023 at 03:31:42PM +0200, Greg KH wrote: > On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote: > > Maybe we just need a commit hook that yells if something with a Fixes: > > tag doesn't have a CC: stable on it? > I could start doing that, it's going to be really noisy... It would need to exclude commits that are only in -next since that's a common legitimate use case for Fixes which shouldn't have a Cc to stable, and there's going to be a bunch of false positives from people who are overly enthusiastic in their use of fixes tags. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX 2023-07-10 13:47 ` Mark Brown @ 2023-07-10 14:09 ` Greg KH 0 siblings, 0 replies; 13+ messages in thread From: Greg KH @ 2023-07-10 14:09 UTC (permalink / raw) To: Mark Brown Cc: Will Deacon, Sasha Levin, linux-kernel, stable, Kristina Martsenko, Catalin Marinas, james.morse, mark.rutland, amit.kachhap, maz, anshuman.khandual, joey.gouly, linux-arm-kernel On Mon, Jul 10, 2023 at 02:47:12PM +0100, Mark Brown wrote: > On Mon, Jul 10, 2023 at 03:31:42PM +0200, Greg KH wrote: > > On Mon, Jul 10, 2023 at 10:44:38AM +0100, Will Deacon wrote: > > > > Maybe we just need a commit hook that yells if something with a Fixes: > > > tag doesn't have a CC: stable on it? > > > I could start doing that, it's going to be really noisy... > > It would need to exclude commits that are only in -next since that's a > common legitimate use case for Fixes which shouldn't have a Cc to > stable, and there's going to be a bunch of false positives from people > who are overly enthusiastic in their use of fixes tags. My scripts today already know where the original Fix tag came from, it's not hard to detect. So this should not be an issue, we don't even consider any commit with "Fixes:" in it for a kernel that has not already been released. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH AUTOSEL 6.4 09/12] arm64: set __exception_irq_entry with __irq_entry as a default [not found] <20230702195057.1787686-1-sashal@kernel.org> 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX Sasha Levin @ 2023-07-02 19:50 ` Sasha Levin 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 10/12] arm64: mm: fix VA-range sanity check Sasha Levin 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver Sasha Levin 3 siblings, 0 replies; 13+ messages in thread From: Sasha Levin @ 2023-07-02 19:50 UTC (permalink / raw) To: linux-kernel, stable Cc: Youngmin Nam, SEO HOYOUNG, Mark Rutland, Catalin Marinas, Sasha Levin, will, broonie, anshuman.khandual, jpoimboe, kristina.martsenko, ardb, linux-arm-kernel From: Youngmin Nam <youngmin.nam@samsung.com> [ Upstream commit f6794950f0e5ba37e3bbedda4d6ab0aad7395dd3 ] filter_irq_stacks() is supposed to cut entries which are related irq entries from its call stack. And in_irqentry_text() which is called by filter_irq_stacks() uses __irqentry_text_start/end symbol to find irq entries in callstack. But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER", arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq between __irqentry_text_start and __irqentry_text_end as we discussed in below link. https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t This problem can makes unintentional deep call stack entries especially in KASAN enabled situation as below. [ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity [ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c [ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--) [ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c [ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c [ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0 [ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000 [ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd [ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040 [ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000 [ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20 [ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8 [ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800 [ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8 [ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c [ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022 [ 2479.386231]I[0:launcher-loader: 1719] Call trace: [ 2479.386248]I[0:launcher-loader: 1719] __stack_depot_save+0x464/0x46c [ 2479.386273]I[0:launcher-loader: 1719] kasan_save_stack+0x58/0x70 [ 2479.386303]I[0:launcher-loader: 1719] save_stack_info+0x34/0x138 [ 2479.386331]I[0:launcher-loader: 1719] kasan_save_free_info+0x18/0x24 [ 2479.386358]I[0:launcher-loader: 1719] ____kasan_slab_free+0x16c/0x170 [ 2479.386385]I[0:launcher-loader: 1719] __kasan_slab_free+0x10/0x20 [ 2479.386410]I[0:launcher-loader: 1719] kmem_cache_free+0x238/0x53c [ 2479.386435]I[0:launcher-loader: 1719] mempool_free_slab+0x1c/0x28 [ 2479.386460]I[0:launcher-loader: 1719] mempool_free+0x7c/0x1a0 [ 2479.386484]I[0:launcher-loader: 1719] bvec_free+0x34/0x80 [ 2479.386514]I[0:launcher-loader: 1719] bio_free+0x60/0x98 [ 2479.386540]I[0:launcher-loader: 1719] bio_put+0x50/0x21c [ 2479.386567]I[0:launcher-loader: 1719] f2fs_write_end_io+0x4ac/0x4d0 [ 2479.386594]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386622]I[0:launcher-loader: 1719] __dm_io_complete+0x324/0x37c [ 2479.386650]I[0:launcher-loader: 1719] dm_io_dec_pending+0x60/0xa4 [ 2479.386676]I[0:launcher-loader: 1719] clone_endio+0xf8/0x2f0 [ 2479.386700]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300 [ 2479.386727]I[0:launcher-loader: 1719] blk_update_request+0x258/0x63c [ 2479.386754]I[0:launcher-loader: 1719] scsi_end_request+0x50/0x304 [ 2479.386782]I[0:launcher-loader: 1719] scsi_io_completion+0x88/0x160 [ 2479.386808]I[0:launcher-loader: 1719] scsi_finish_command+0x17c/0x194 [ 2479.386833]I[0:launcher-loader: 1719] scsi_complete+0xcc/0x158 [ 2479.386859]I[0:launcher-loader: 1719] blk_mq_complete_request+0x4c/0x5c [ 2479.386885]I[0:launcher-loader: 1719] scsi_done_internal+0xf4/0x1e0 [ 2479.386910]I[0:launcher-loader: 1719] scsi_done+0x14/0x20 [ 2479.386935]I[0:launcher-loader: 1719] ufshcd_compl_one_cqe+0x578/0x71c [ 2479.386963]I[0:launcher-loader: 1719] ufshcd_mcq_poll_cqe_nolock+0xc8/0x150 [ 2479.386991]I[0:launcher-loader: 1719] ufshcd_intr+0x868/0xc0c [ 2479.387017]I[0:launcher-loader: 1719] __handle_irq_event_percpu+0xd0/0x348 [ 2479.387044]I[0:launcher-loader: 1719] handle_irq_event_percpu+0x24/0x74 [ 2479.387068]I[0:launcher-loader: 1719] handle_irq_event+0x74/0xe0 [ 2479.387091]I[0:launcher-loader: 1719] handle_fasteoi_irq+0x174/0x240 [ 2479.387118]I[0:launcher-loader: 1719] handle_irq_desc+0x7c/0x2c0 [ 2479.387147]I[0:launcher-loader: 1719] generic_handle_domain_irq+0x1c/0x28 [ 2479.387174]I[0:launcher-loader: 1719] gic_handle_irq+0x64/0x158 [ 2479.387204]I[0:launcher-loader: 1719] call_on_irq_stack+0x2c/0x54 [ 2479.387231]I[0:launcher-loader: 1719] do_interrupt_handler+0x70/0xa0 [ 2479.387258]I[0:launcher-loader: 1719] el1_interrupt+0x34/0x68 [ 2479.387283]I[0:launcher-loader: 1719] el1h_64_irq_handler+0x18/0x24 [ 2479.387308]I[0:launcher-loader: 1719] el1h_64_irq+0x68/0x6c [ 2479.387332]I[0:launcher-loader: 1719] blk_attempt_bio_merge+0x8/0x170 [ 2479.387356]I[0:launcher-loader: 1719] blk_mq_attempt_bio_merge+0x78/0x98 [ 2479.387383]I[0:launcher-loader: 1719] blk_mq_submit_bio+0x324/0xa40 [ 2479.387409]I[0:launcher-loader: 1719] __submit_bio+0x104/0x138 [ 2479.387436]I[0:launcher-loader: 1719] submit_bio_noacct_nocheck+0x1d0/0x4a0 [ 2479.387462]I[0:launcher-loader: 1719] submit_bio_noacct+0x618/0x804 [ 2479.387487]I[0:launcher-loader: 1719] submit_bio+0x164/0x180 [ 2479.387511]I[0:launcher-loader: 1719] f2fs_submit_read_bio+0xe4/0x1c4 [ 2479.387537]I[0:launcher-loader: 1719] f2fs_mpage_readpages+0x888/0xa4c [ 2479.387563]I[0:launcher-loader: 1719] f2fs_readahead+0xd4/0x19c [ 2479.387587]I[0:launcher-loader: 1719] read_pages+0xb0/0x4ac [ 2479.387614]I[0:launcher-loader: 1719] page_cache_ra_unbounded+0x238/0x288 [ 2479.387642]I[0:launcher-loader: 1719] do_page_cache_ra+0x60/0x6c [ 2479.387669]I[0:launcher-loader: 1719] page_cache_ra_order+0x318/0x364 [ 2479.387695]I[0:launcher-loader: 1719] ondemand_readahead+0x30c/0x3d8 [ 2479.387722]I[0:launcher-loader: 1719] page_cache_sync_ra+0xb4/0xc8 [ 2479.387749]I[0:launcher-loader: 1719] filemap_read+0x268/0xd24 [ 2479.387777]I[0:launcher-loader: 1719] f2fs_file_read_iter+0x1a0/0x62c [ 2479.387806]I[0:launcher-loader: 1719] vfs_read+0x258/0x34c [ 2479.387831]I[0:launcher-loader: 1719] ksys_pread64+0x8c/0xd0 [ 2479.387857]I[0:launcher-loader: 1719] __arm64_sys_pread64+0x48/0x54 [ 2479.387881]I[0:launcher-loader: 1719] invoke_syscall+0x58/0x158 [ 2479.387909]I[0:launcher-loader: 1719] el0_svc_common+0xf0/0x134 [ 2479.387935]I[0:launcher-loader: 1719] do_el0_svc+0x44/0x114 [ 2479.387961]I[0:launcher-loader: 1719] el0_svc+0x2c/0x80 [ 2479.387985]I[0:launcher-loader: 1719] el0t_64_sync_handler+0x48/0x114 [ 2479.388010]I[0:launcher-loader: 1719] el0t_64_sync+0x190/0x194 [ 2479.388038]I[0:launcher-loader: 1719] Kernel panic - not syncing: kernel: panic_on_warn set ... So let's set __exception_irq_entry with __irq_entry as a default. Applying this patch, we can see gic_hande_irq is included in Systemp.map as below. * Before ffffffc008010000 T __do_softirq ffffffc008010000 T __irqentry_text_end ffffffc008010000 T __irqentry_text_start ffffffc008010000 T __softirqentry_text_start ffffffc008010000 T _stext ffffffc00801066c T __softirqentry_text_end ffffffc008010670 T __entry_text_start * After ffffffc008010000 T __irqentry_text_start ffffffc008010000 T _stext ffffffc008010000 t gic_handle_irq ffffffc00801013c t gic_handle_irq ffffffc008010294 T __irqentry_text_end ffffffc008010298 T __do_softirq ffffffc008010298 T __softirqentry_text_start ffffffc008010904 T __softirqentry_text_end ffffffc008010908 T __entry_text_start Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com> Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20230424010436.779733-1-youngmin.nam@samsung.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/include/asm/exception.h | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/arm64/include/asm/exception.h b/arch/arm64/include/asm/exception.h index e73af709cb7ad..88d8dfeed0db6 100644 --- a/arch/arm64/include/asm/exception.h +++ b/arch/arm64/include/asm/exception.h @@ -8,16 +8,11 @@ #define __ASM_EXCEPTION_H #include <asm/esr.h> -#include <asm/kprobes.h> #include <asm/ptrace.h> #include <linux/interrupt.h> -#ifdef CONFIG_FUNCTION_GRAPH_TRACER #define __exception_irq_entry __irq_entry -#else -#define __exception_irq_entry __kprobes -#endif static inline unsigned long disr_to_esr(u64 disr) { -- 2.39.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH AUTOSEL 6.4 10/12] arm64: mm: fix VA-range sanity check [not found] <20230702195057.1787686-1-sashal@kernel.org> 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX Sasha Levin 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 09/12] arm64: set __exception_irq_entry with __irq_entry as a default Sasha Levin @ 2023-07-02 19:50 ` Sasha Levin 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver Sasha Levin 3 siblings, 0 replies; 13+ messages in thread From: Sasha Levin @ 2023-07-02 19:50 UTC (permalink / raw) To: linux-kernel, stable Cc: Mark Rutland, Russell King, Steve Capper, Will Deacon, Russell King, Catalin Marinas, Sasha Levin, anshuman.khandual, wangkefeng.wang, quic_zhenhuah, chenfeiyang, bhe, linux-arm-kernel From: Mark Rutland <mark.rutland@arm.com> [ Upstream commit ab9b4008092c86dc12497af155a0901cc1156999 ] Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident. The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } ... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings. When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation") ... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; } At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1. Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space") ... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map. Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END") ... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } Correct the condition to check against the start of the TTBR1 address space, which is currently PAGE_OFFSET. This simplifies the logic, and more clearly matches the "outside kernel range" message in the warning. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Steve Capper <steve.capper@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm64/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index af6bc8403ee46..72b3c21820b96 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -451,7 +451,7 @@ static phys_addr_t pgd_pgtable_alloc(int shift) void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt, phys_addr_t size, pgprot_t prot) { - if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + if (virt < PAGE_OFFSET) { pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n", &phys, virt); return; @@ -478,7 +478,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys, static void update_mapping_prot(phys_addr_t phys, unsigned long virt, phys_addr_t size, pgprot_t prot) { - if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { + if (virt < PAGE_OFFSET) { pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n", &phys, virt); return; -- 2.39.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver [not found] <20230702195057.1787686-1-sashal@kernel.org> ` (2 preceding siblings ...) 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 10/12] arm64: mm: fix VA-range sanity check Sasha Levin @ 2023-07-02 19:50 ` Sasha Levin 2023-07-03 10:14 ` Mark Rutland 3 siblings, 1 reply; 13+ messages in thread From: Sasha Levin @ 2023-07-02 19:50 UTC (permalink / raw) To: linux-kernel, stable Cc: Junhao He, Jonathan Cameron, Yicong Yang, Mark Rutland, Will Deacon, Sasha Levin, zhangshaokun, jonathan.cameron, linux-arm-kernel From: Junhao He <hejunhao3@huawei.com> [ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ] Compared to the original PA device, H60PA offers higher bandwidth. The H60PA is a new device and we use HID to differentiate them. The events supported by PAv3 and PAv2 are different. The PAv3 PMU removed some events which are supported by PAv2 PMU. The older PA PMU driver will probe v3 as v2. Therefore PA events displayed by "perf list" cannot work properly. We add the HISI0275 HID for PAv3 PMU to distinguish different. For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow. Signed-off-by: Junhao He <hejunhao3@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ 2 files changed, 120 insertions(+), 15 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c index 71b6687d66960..d941e746b4248 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c @@ -22,9 +22,15 @@ #define PA_TT_CTRL 0x1c08 #define PA_TGTID_CTRL 0x1c14 #define PA_SRCID_CTRL 0x1c18 + +/* H32 PA interrupt registers */ #define PA_INT_MASK 0x1c70 #define PA_INT_STATUS 0x1c78 #define PA_INT_CLEAR 0x1c7c + +#define H60PA_INT_STATUS 0x1c70 +#define H60PA_INT_MASK 0x1c74 + #define PA_EVENT_TYPE0 0x1c80 #define PA_PMU_VERSION 0x1cf0 #define PA_EVENT_CNT0_L 0x1d00 @@ -46,6 +52,12 @@ HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_cmd, config1, 32, 22); HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_msk, config1, 43, 33); HISI_PMU_EVENT_ATTR_EXTRACTOR(tracetag_en, config1, 44, 44); +struct hisi_pa_pmu_int_regs { + u32 mask_offset; + u32 clear_offset; + u32 status_offset; +}; + static void hisi_pa_pmu_enable_tracetag(struct perf_event *event) { struct hisi_pmu *pa_pmu = to_hisi_pmu(event->pmu); @@ -219,40 +231,40 @@ static void hisi_pa_pmu_disable_counter(struct hisi_pmu *pa_pmu, static void hisi_pa_pmu_enable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) { + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val; /* Write 0 to enable interrupt */ - val = readl(pa_pmu->base + PA_INT_MASK); + val = readl(pa_pmu->base + regs->mask_offset); val &= ~(1 << hwc->idx); - writel(val, pa_pmu->base + PA_INT_MASK); + writel(val, pa_pmu->base + regs->mask_offset); } static void hisi_pa_pmu_disable_counter_int(struct hisi_pmu *pa_pmu, struct hw_perf_event *hwc) { + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; u32 val; /* Write 1 to mask interrupt */ - val = readl(pa_pmu->base + PA_INT_MASK); + val = readl(pa_pmu->base + regs->mask_offset); val |= 1 << hwc->idx; - writel(val, pa_pmu->base + PA_INT_MASK); + writel(val, pa_pmu->base + regs->mask_offset); } static u32 hisi_pa_pmu_get_int_status(struct hisi_pmu *pa_pmu) { - return readl(pa_pmu->base + PA_INT_STATUS); + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; + + return readl(pa_pmu->base + regs->status_offset); } static void hisi_pa_pmu_clear_int_status(struct hisi_pmu *pa_pmu, int idx) { - writel(1 << idx, pa_pmu->base + PA_INT_CLEAR); -} + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; -static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { - { "HISI0273", }, - {} -}; -MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); + writel(1 << idx, pa_pmu->base + regs->clear_offset); +} static int hisi_pa_pmu_init_data(struct platform_device *pdev, struct hisi_pmu *pa_pmu) @@ -276,6 +288,10 @@ static int hisi_pa_pmu_init_data(struct platform_device *pdev, pa_pmu->ccl_id = -1; pa_pmu->sccl_id = -1; + pa_pmu->dev_info = device_get_match_data(&pdev->dev); + if (!pa_pmu->dev_info) + return -ENODEV; + pa_pmu->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(pa_pmu->base)) { dev_err(&pdev->dev, "ioremap failed for pa_pmu resource.\n"); @@ -314,6 +330,32 @@ static const struct attribute_group hisi_pa_pmu_v2_events_group = { .attrs = hisi_pa_pmu_v2_events_attr, }; +static struct attribute *hisi_pa_pmu_v3_events_attr[] = { + HISI_PMU_EVENT_ATTR(tx_req, 0x0), + HISI_PMU_EVENT_ATTR(tx_dat, 0x1), + HISI_PMU_EVENT_ATTR(tx_snp, 0x2), + HISI_PMU_EVENT_ATTR(rx_req, 0x7), + HISI_PMU_EVENT_ATTR(rx_dat, 0x8), + HISI_PMU_EVENT_ATTR(rx_snp, 0x9), + NULL +}; + +static const struct attribute_group hisi_pa_pmu_v3_events_group = { + .name = "events", + .attrs = hisi_pa_pmu_v3_events_attr, +}; + +static struct attribute *hisi_h60pa_pmu_events_attr[] = { + HISI_PMU_EVENT_ATTR(rx_flit, 0x50), + HISI_PMU_EVENT_ATTR(tx_flit, 0x65), + NULL +}; + +static const struct attribute_group hisi_h60pa_pmu_events_group = { + .name = "events", + .attrs = hisi_h60pa_pmu_events_attr, +}; + static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL); static struct attribute *hisi_pa_pmu_cpumask_attrs[] = { @@ -337,6 +379,12 @@ static const struct attribute_group hisi_pa_pmu_identifier_group = { .attrs = hisi_pa_pmu_identifier_attrs, }; +static struct hisi_pa_pmu_int_regs hisi_pa_pmu_regs = { + .mask_offset = PA_INT_MASK, + .clear_offset = PA_INT_CLEAR, + .status_offset = PA_INT_STATUS, +}; + static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { &hisi_pa_pmu_v2_format_group, &hisi_pa_pmu_v2_events_group, @@ -345,6 +393,46 @@ static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { NULL }; +static const struct hisi_pmu_dev_info hisi_h32pa_v2 = { + .name = "pa", + .attr_groups = hisi_pa_pmu_v2_attr_groups, + .private = &hisi_pa_pmu_regs, +}; + +static const struct attribute_group *hisi_pa_pmu_v3_attr_groups[] = { + &hisi_pa_pmu_v2_format_group, + &hisi_pa_pmu_v3_events_group, + &hisi_pa_pmu_cpumask_attr_group, + &hisi_pa_pmu_identifier_group, + NULL +}; + +static const struct hisi_pmu_dev_info hisi_h32pa_v3 = { + .name = "pa", + .attr_groups = hisi_pa_pmu_v3_attr_groups, + .private = &hisi_pa_pmu_regs, +}; + +static struct hisi_pa_pmu_int_regs hisi_h60pa_pmu_regs = { + .mask_offset = H60PA_INT_MASK, + .clear_offset = H60PA_INT_STATUS, /* Clear on write */ + .status_offset = H60PA_INT_STATUS, +}; + +static const struct attribute_group *hisi_h60pa_pmu_attr_groups[] = { + &hisi_pa_pmu_v2_format_group, + &hisi_h60pa_pmu_events_group, + &hisi_pa_pmu_cpumask_attr_group, + &hisi_pa_pmu_identifier_group, + NULL +}; + +static const struct hisi_pmu_dev_info hisi_h60pa = { + .name = "h60pa", + .attr_groups = hisi_h60pa_pmu_attr_groups, + .private = &hisi_h60pa_pmu_regs, +}; + static const struct hisi_uncore_ops hisi_uncore_pa_ops = { .write_evtype = hisi_pa_pmu_write_evtype, .get_event_idx = hisi_uncore_pmu_get_event_idx, @@ -375,7 +463,7 @@ static int hisi_pa_pmu_dev_probe(struct platform_device *pdev, if (ret) return ret; - pa_pmu->pmu_events.attr_groups = hisi_pa_pmu_v2_attr_groups; + pa_pmu->pmu_events.attr_groups = pa_pmu->dev_info->attr_groups; pa_pmu->num_counters = PA_NR_COUNTERS; pa_pmu->ops = &hisi_uncore_pa_ops; pa_pmu->check_event = 0xB0; @@ -400,8 +488,9 @@ static int hisi_pa_pmu_probe(struct platform_device *pdev) if (ret) return ret; - name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%u_pa%u", - pa_pmu->sicl_id, pa_pmu->index_id); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%d_%s%u", + pa_pmu->sicl_id, pa_pmu->dev_info->name, + pa_pmu->index_id); if (!name) return -ENOMEM; @@ -435,6 +524,14 @@ static int hisi_pa_pmu_remove(struct platform_device *pdev) return 0; } +static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { + { "HISI0273", (kernel_ulong_t)&hisi_h32pa_v2 }, + { "HISI0275", (kernel_ulong_t)&hisi_h32pa_v3 }, + { "HISI0274", (kernel_ulong_t)&hisi_h60pa }, + {} +}; +MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); + static struct platform_driver hisi_pa_pmu_driver = { .driver = { .name = "hisi_pa_pmu", diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.h b/drivers/perf/hisilicon/hisi_uncore_pmu.h index 07890a8e96ca7..772857b99dc5e 100644 --- a/drivers/perf/hisilicon/hisi_uncore_pmu.h +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.h @@ -62,6 +62,13 @@ struct hisi_uncore_ops { void (*disable_filter)(struct perf_event *event); }; +/* Describes the HISI PMU chip features information */ +struct hisi_pmu_dev_info { + const char *name; + const struct attribute_group **attr_groups; + void *private; +}; + struct hisi_pmu_hwevents { struct perf_event *hw_events[HISI_MAX_COUNTERS]; DECLARE_BITMAP(used_mask, HISI_MAX_COUNTERS); @@ -72,6 +79,7 @@ struct hisi_pmu_hwevents { struct hisi_pmu { struct pmu pmu; const struct hisi_uncore_ops *ops; + const struct hisi_pmu_dev_info *dev_info; struct hisi_pmu_hwevents pmu_events; /* associated_cpus: All CPUs associated with the PMU */ cpumask_t associated_cpus; -- 2.39.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver 2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver Sasha Levin @ 2023-07-03 10:14 ` Mark Rutland 2023-07-21 15:13 ` Sasha Levin 0 siblings, 1 reply; 13+ messages in thread From: Mark Rutland @ 2023-07-03 10:14 UTC (permalink / raw) To: Sasha Levin Cc: linux-kernel, stable, Junhao He, Jonathan Cameron, Yicong Yang, Will Deacon, zhangshaokun, linux-arm-kernel On Sun, Jul 02, 2023 at 03:50:56PM -0400, Sasha Levin wrote: > From: Junhao He <hejunhao3@huawei.com> > > [ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ] > > Compared to the original PA device, H60PA offers higher bandwidth. > The H60PA is a new device and we use HID to differentiate them. > > The events supported by PAv3 and PAv2 are different. The PAv3 PMU > removed some events which are supported by PAv2 PMU. The older PA > PMU driver will probe v3 as v2. Therefore PA events displayed by > "perf list" cannot work properly. We add the HISI0275 HID for PAv3 > PMU to distinguish different. > > For each H60PA PMU, except for the overflow interrupt register, other > functions of the H60PA PMU are the same as the original PA PMU module. > It has 8-programable counters and each counter is free-running. > Interrupt is supported to handle counter (64-bits) overflow. > > Signed-off-by: Junhao He <hejunhao3@huawei.com> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> > Acked-by: Mark Rutland <mark.rutland@arm.com> > Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com > Signed-off-by: Will Deacon <will@kernel.org> > Signed-off-by: Sasha Levin <sashal@kernel.org> > --- > drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- > drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ > 2 files changed, 120 insertions(+), 15 deletions(-) Why is this being backported to stable? This patch adds supoprt for new HW, and is clearly not a fix, so it's not clear to me why it has been selected. Thanks, Mark. > diff --git a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c > index 71b6687d66960..d941e746b4248 100644 > --- a/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c > +++ b/drivers/perf/hisilicon/hisi_uncore_pa_pmu.c > @@ -22,9 +22,15 @@ > #define PA_TT_CTRL 0x1c08 > #define PA_TGTID_CTRL 0x1c14 > #define PA_SRCID_CTRL 0x1c18 > + > +/* H32 PA interrupt registers */ > #define PA_INT_MASK 0x1c70 > #define PA_INT_STATUS 0x1c78 > #define PA_INT_CLEAR 0x1c7c > + > +#define H60PA_INT_STATUS 0x1c70 > +#define H60PA_INT_MASK 0x1c74 > + > #define PA_EVENT_TYPE0 0x1c80 > #define PA_PMU_VERSION 0x1cf0 > #define PA_EVENT_CNT0_L 0x1d00 > @@ -46,6 +52,12 @@ HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_cmd, config1, 32, 22); > HISI_PMU_EVENT_ATTR_EXTRACTOR(srcid_msk, config1, 43, 33); > HISI_PMU_EVENT_ATTR_EXTRACTOR(tracetag_en, config1, 44, 44); > > +struct hisi_pa_pmu_int_regs { > + u32 mask_offset; > + u32 clear_offset; > + u32 status_offset; > +}; > + > static void hisi_pa_pmu_enable_tracetag(struct perf_event *event) > { > struct hisi_pmu *pa_pmu = to_hisi_pmu(event->pmu); > @@ -219,40 +231,40 @@ static void hisi_pa_pmu_disable_counter(struct hisi_pmu *pa_pmu, > static void hisi_pa_pmu_enable_counter_int(struct hisi_pmu *pa_pmu, > struct hw_perf_event *hwc) > { > + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; > u32 val; > > /* Write 0 to enable interrupt */ > - val = readl(pa_pmu->base + PA_INT_MASK); > + val = readl(pa_pmu->base + regs->mask_offset); > val &= ~(1 << hwc->idx); > - writel(val, pa_pmu->base + PA_INT_MASK); > + writel(val, pa_pmu->base + regs->mask_offset); > } > > static void hisi_pa_pmu_disable_counter_int(struct hisi_pmu *pa_pmu, > struct hw_perf_event *hwc) > { > + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; > u32 val; > > /* Write 1 to mask interrupt */ > - val = readl(pa_pmu->base + PA_INT_MASK); > + val = readl(pa_pmu->base + regs->mask_offset); > val |= 1 << hwc->idx; > - writel(val, pa_pmu->base + PA_INT_MASK); > + writel(val, pa_pmu->base + regs->mask_offset); > } > > static u32 hisi_pa_pmu_get_int_status(struct hisi_pmu *pa_pmu) > { > - return readl(pa_pmu->base + PA_INT_STATUS); > + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; > + > + return readl(pa_pmu->base + regs->status_offset); > } > > static void hisi_pa_pmu_clear_int_status(struct hisi_pmu *pa_pmu, int idx) > { > - writel(1 << idx, pa_pmu->base + PA_INT_CLEAR); > -} > + struct hisi_pa_pmu_int_regs *regs = pa_pmu->dev_info->private; > > -static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { > - { "HISI0273", }, > - {} > -}; > -MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); > + writel(1 << idx, pa_pmu->base + regs->clear_offset); > +} > > static int hisi_pa_pmu_init_data(struct platform_device *pdev, > struct hisi_pmu *pa_pmu) > @@ -276,6 +288,10 @@ static int hisi_pa_pmu_init_data(struct platform_device *pdev, > pa_pmu->ccl_id = -1; > pa_pmu->sccl_id = -1; > > + pa_pmu->dev_info = device_get_match_data(&pdev->dev); > + if (!pa_pmu->dev_info) > + return -ENODEV; > + > pa_pmu->base = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(pa_pmu->base)) { > dev_err(&pdev->dev, "ioremap failed for pa_pmu resource.\n"); > @@ -314,6 +330,32 @@ static const struct attribute_group hisi_pa_pmu_v2_events_group = { > .attrs = hisi_pa_pmu_v2_events_attr, > }; > > +static struct attribute *hisi_pa_pmu_v3_events_attr[] = { > + HISI_PMU_EVENT_ATTR(tx_req, 0x0), > + HISI_PMU_EVENT_ATTR(tx_dat, 0x1), > + HISI_PMU_EVENT_ATTR(tx_snp, 0x2), > + HISI_PMU_EVENT_ATTR(rx_req, 0x7), > + HISI_PMU_EVENT_ATTR(rx_dat, 0x8), > + HISI_PMU_EVENT_ATTR(rx_snp, 0x9), > + NULL > +}; > + > +static const struct attribute_group hisi_pa_pmu_v3_events_group = { > + .name = "events", > + .attrs = hisi_pa_pmu_v3_events_attr, > +}; > + > +static struct attribute *hisi_h60pa_pmu_events_attr[] = { > + HISI_PMU_EVENT_ATTR(rx_flit, 0x50), > + HISI_PMU_EVENT_ATTR(tx_flit, 0x65), > + NULL > +}; > + > +static const struct attribute_group hisi_h60pa_pmu_events_group = { > + .name = "events", > + .attrs = hisi_h60pa_pmu_events_attr, > +}; > + > static DEVICE_ATTR(cpumask, 0444, hisi_cpumask_sysfs_show, NULL); > > static struct attribute *hisi_pa_pmu_cpumask_attrs[] = { > @@ -337,6 +379,12 @@ static const struct attribute_group hisi_pa_pmu_identifier_group = { > .attrs = hisi_pa_pmu_identifier_attrs, > }; > > +static struct hisi_pa_pmu_int_regs hisi_pa_pmu_regs = { > + .mask_offset = PA_INT_MASK, > + .clear_offset = PA_INT_CLEAR, > + .status_offset = PA_INT_STATUS, > +}; > + > static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { > &hisi_pa_pmu_v2_format_group, > &hisi_pa_pmu_v2_events_group, > @@ -345,6 +393,46 @@ static const struct attribute_group *hisi_pa_pmu_v2_attr_groups[] = { > NULL > }; > > +static const struct hisi_pmu_dev_info hisi_h32pa_v2 = { > + .name = "pa", > + .attr_groups = hisi_pa_pmu_v2_attr_groups, > + .private = &hisi_pa_pmu_regs, > +}; > + > +static const struct attribute_group *hisi_pa_pmu_v3_attr_groups[] = { > + &hisi_pa_pmu_v2_format_group, > + &hisi_pa_pmu_v3_events_group, > + &hisi_pa_pmu_cpumask_attr_group, > + &hisi_pa_pmu_identifier_group, > + NULL > +}; > + > +static const struct hisi_pmu_dev_info hisi_h32pa_v3 = { > + .name = "pa", > + .attr_groups = hisi_pa_pmu_v3_attr_groups, > + .private = &hisi_pa_pmu_regs, > +}; > + > +static struct hisi_pa_pmu_int_regs hisi_h60pa_pmu_regs = { > + .mask_offset = H60PA_INT_MASK, > + .clear_offset = H60PA_INT_STATUS, /* Clear on write */ > + .status_offset = H60PA_INT_STATUS, > +}; > + > +static const struct attribute_group *hisi_h60pa_pmu_attr_groups[] = { > + &hisi_pa_pmu_v2_format_group, > + &hisi_h60pa_pmu_events_group, > + &hisi_pa_pmu_cpumask_attr_group, > + &hisi_pa_pmu_identifier_group, > + NULL > +}; > + > +static const struct hisi_pmu_dev_info hisi_h60pa = { > + .name = "h60pa", > + .attr_groups = hisi_h60pa_pmu_attr_groups, > + .private = &hisi_h60pa_pmu_regs, > +}; > + > static const struct hisi_uncore_ops hisi_uncore_pa_ops = { > .write_evtype = hisi_pa_pmu_write_evtype, > .get_event_idx = hisi_uncore_pmu_get_event_idx, > @@ -375,7 +463,7 @@ static int hisi_pa_pmu_dev_probe(struct platform_device *pdev, > if (ret) > return ret; > > - pa_pmu->pmu_events.attr_groups = hisi_pa_pmu_v2_attr_groups; > + pa_pmu->pmu_events.attr_groups = pa_pmu->dev_info->attr_groups; > pa_pmu->num_counters = PA_NR_COUNTERS; > pa_pmu->ops = &hisi_uncore_pa_ops; > pa_pmu->check_event = 0xB0; > @@ -400,8 +488,9 @@ static int hisi_pa_pmu_probe(struct platform_device *pdev) > if (ret) > return ret; > > - name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%u_pa%u", > - pa_pmu->sicl_id, pa_pmu->index_id); > + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "hisi_sicl%d_%s%u", > + pa_pmu->sicl_id, pa_pmu->dev_info->name, > + pa_pmu->index_id); > if (!name) > return -ENOMEM; > > @@ -435,6 +524,14 @@ static int hisi_pa_pmu_remove(struct platform_device *pdev) > return 0; > } > > +static const struct acpi_device_id hisi_pa_pmu_acpi_match[] = { > + { "HISI0273", (kernel_ulong_t)&hisi_h32pa_v2 }, > + { "HISI0275", (kernel_ulong_t)&hisi_h32pa_v3 }, > + { "HISI0274", (kernel_ulong_t)&hisi_h60pa }, > + {} > +}; > +MODULE_DEVICE_TABLE(acpi, hisi_pa_pmu_acpi_match); > + > static struct platform_driver hisi_pa_pmu_driver = { > .driver = { > .name = "hisi_pa_pmu", > diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.h b/drivers/perf/hisilicon/hisi_uncore_pmu.h > index 07890a8e96ca7..772857b99dc5e 100644 > --- a/drivers/perf/hisilicon/hisi_uncore_pmu.h > +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.h > @@ -62,6 +62,13 @@ struct hisi_uncore_ops { > void (*disable_filter)(struct perf_event *event); > }; > > +/* Describes the HISI PMU chip features information */ > +struct hisi_pmu_dev_info { > + const char *name; > + const struct attribute_group **attr_groups; > + void *private; > +}; > + > struct hisi_pmu_hwevents { > struct perf_event *hw_events[HISI_MAX_COUNTERS]; > DECLARE_BITMAP(used_mask, HISI_MAX_COUNTERS); > @@ -72,6 +79,7 @@ struct hisi_pmu_hwevents { > struct hisi_pmu { > struct pmu pmu; > const struct hisi_uncore_ops *ops; > + const struct hisi_pmu_dev_info *dev_info; > struct hisi_pmu_hwevents pmu_events; > /* associated_cpus: All CPUs associated with the PMU */ > cpumask_t associated_cpus; > -- > 2.39.2 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver 2023-07-03 10:14 ` Mark Rutland @ 2023-07-21 15:13 ` Sasha Levin 0 siblings, 0 replies; 13+ messages in thread From: Sasha Levin @ 2023-07-21 15:13 UTC (permalink / raw) To: Mark Rutland Cc: linux-kernel, stable, Junhao He, Jonathan Cameron, Yicong Yang, Will Deacon, zhangshaokun, linux-arm-kernel On Mon, Jul 03, 2023 at 11:14:37AM +0100, Mark Rutland wrote: >On Sun, Jul 02, 2023 at 03:50:56PM -0400, Sasha Levin wrote: >> From: Junhao He <hejunhao3@huawei.com> >> >> [ Upstream commit 1a51688474c0d395b864e98236335fba712e29bf ] >> >> Compared to the original PA device, H60PA offers higher bandwidth. >> The H60PA is a new device and we use HID to differentiate them. >> >> The events supported by PAv3 and PAv2 are different. The PAv3 PMU >> removed some events which are supported by PAv2 PMU. The older PA >> PMU driver will probe v3 as v2. Therefore PA events displayed by >> "perf list" cannot work properly. We add the HISI0275 HID for PAv3 >> PMU to distinguish different. >> >> For each H60PA PMU, except for the overflow interrupt register, other >> functions of the H60PA PMU are the same as the original PA PMU module. >> It has 8-programable counters and each counter is free-running. >> Interrupt is supported to handle counter (64-bits) overflow. >> >> Signed-off-by: Junhao He <hejunhao3@huawei.com> >> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> >> Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> >> Acked-by: Mark Rutland <mark.rutland@arm.com> >> Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com >> Signed-off-by: Will Deacon <will@kernel.org> >> Signed-off-by: Sasha Levin <sashal@kernel.org> >> --- >> drivers/perf/hisilicon/hisi_uncore_pa_pmu.c | 127 +++++++++++++++++--- >> drivers/perf/hisilicon/hisi_uncore_pmu.h | 8 ++ >> 2 files changed, 120 insertions(+), 15 deletions(-) > >Why is this being backported to stable? > >This patch adds supoprt for new HW, and is clearly not a fix, so it's not clear >to me why it has been selected. I'll drop it, thanks. -- Thanks, Sasha _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-07-21 15:14 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230702195057.1787686-1-sashal@kernel.org>
2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 07/12] arm64: cpufeature: detect FEAT_HCX Sasha Levin
2023-07-03 11:51 ` Mark Brown
2023-07-09 14:56 ` Sasha Levin
2023-07-09 21:13 ` Mark Brown
2023-07-10 9:44 ` Will Deacon
2023-07-10 13:31 ` Greg KH
2023-07-10 13:47 ` Mark Brown
2023-07-10 14:09 ` Greg KH
2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 09/12] arm64: set __exception_irq_entry with __irq_entry as a default Sasha Levin
2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 10/12] arm64: mm: fix VA-range sanity check Sasha Levin
2023-07-02 19:50 ` [PATCH AUTOSEL 6.4 11/12] drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver Sasha Levin
2023-07-03 10:14 ` Mark Rutland
2023-07-21 15:13 ` Sasha Levin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).