From: Mark Rutland <mark.rutland@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, will@kernel.org,
catalin.marinas@arm.com, Mark Brown <broonie@kernel.org>,
James Clark <james.clark@arm.com>, Rob Herring <robh@kernel.org>,
Marc Zyngier <maz@kernel.org>,
Suzuki Poulose <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V11 02/10] arm64/perf: Add BRBE registers and fields
Date: Mon, 5 Jun 2023 08:55:27 +0100 [thread overview]
Message-ID: <ZH2U79ZP7HXNJctA@FVFF77S0Q05N> (raw)
In-Reply-To: <20230531040428.501523-3-anshuman.khandual@arm.com>
Hi ANshuman,
This looks good to me, with some minor nits on enum value naming and field
formatting.
On Wed, May 31, 2023 at 09:34:20AM +0530, Anshuman Khandual wrote:
> This adds BRBE related register definitions and various other related field
> macros there in. These will be used subsequently in a BRBE driver which is
> being added later on.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Tested-by: James Clark <james.clark@arm.com>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 103 +++++++++++++++++++++
> arch/arm64/tools/sysreg | 159 ++++++++++++++++++++++++++++++++
> 2 files changed, 262 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index e72d9aaab6b1..12419c55d3b7 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -165,6 +165,109 @@
> #define SYS_DBGDTRTX_EL0 sys_reg(2, 3, 0, 5, 0)
> #define SYS_DBGVCR32_EL2 sys_reg(2, 4, 0, 7, 0)
>
> +#define __SYS_BRBINFO(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 0))
> +#define __SYS_BRBSRC(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 1))
> +#define __SYS_BRBTGT(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 2))
These look correct to me per ARM DDI 0487J.a
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c9a0d1fa3209..44745f42262f 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -947,6 +947,165 @@ UnsignedEnum 3:0 BT
> EndEnum
> EndSysreg
>
> +
> +SysregFields BRBINFx_EL1
> +Res0 63:47
> +Field 46 CCU
> +Field 45:32 CC
> +Res0 31:18
> +Field 17 LASTFAILED
> +Field 16 T
> +Res0 15:14
> +Enum 13:8 TYPE
> + 0b000000 UNCOND_DIR
> + 0b000001 INDIR
> + 0b000010 DIR_LINK
> + 0b000011 INDIR_LINK
For clarity, I'd prefer that we use "DIRECT" and "INDIRECT" in full for each of
these, i.e.
0b000000 UNCOND_DIRECT
0b000001 INDIRECT
0b000010 DIRECT_LINK
0b000011 INDIRECT_LINK
> + 0b000101 RET_SUB
> + 0b000111 RET_EXCPT
Similarly, I'm not keen on the suffixes here.
I think these would be clearer as "RET" and "ERET", as those are short and
unambiguous, and I think the alternative of spelling out "RET_SUBROUTINE" and
"RET_EXCEPTION" is overly verbose.
> + 0b001000 COND_DIR
As with above, I'd prefer "COND_DIRECT" here.
> + 0b100001 DEBUG_HALT
> + 0b100010 CALL
> + 0b100011 TRAP
> + 0b100100 SERROR
> + 0b100110 INST_DEBUG
We generally use 'insn' rather than 'inst', so I'd prefer s/INST/INSN/ here.
> + 0b100111 DATA_DEBUG
> + 0b101010 ALGN_FAULT
s/ALGN/ALIGN/
> + 0b101011 INST_FAULT
As above, I'd prefer "INSN_FAULT" here, though I'm confused that the
architecture doesn't use "abort" naming for this.
> + 0b101100 DATA_FAULT
> + 0b101110 IRQ
> + 0b101111 FIQ
> + 0b111001 DEBUG_EXIT
> +EndEnum
[...]
+Sysreg BRBCR_EL1 2 1 9 0 0
> +Res0 63:24
> +Field 23 EXCEPTION
> +Field 22 ERTN
> +Res0 21:9
> +Field 8 FZP
> +Res0 7
> +Enum 6:5 TS
> + 0b01 VIRTUAL
> + 0b10 GST_PHYSICAL
s/GST/GUEST/
> + 0b11 PHYSICAL
> +EndEnum
> +Field 4 MPRED
> +Field 3 CC
> +Res0 2
> +Field 1 E1BRE
> +Field 0 E0BRE
> +EndSysreg
[...]
> +Sysreg BRBINFINJ_EL1 2 1 9 1 0
> +Res0 63:47
> +Field 46 CCU
> +Field 45:32 CC
> +Res0 31:18
> +Field 17 LASTFAILED
> +Field 16 T
> +Res0 15:14
> +Enum 13:8 TYPE
> + 0b000000 UNCOND_DIR
> + 0b000001 INDIR
> + 0b000010 DIR_LINK
> + 0b000011 INDIR_LINK
> + 0b000100 RET_SUB
> + 0b000100 RET_SUB
> + 0b000111 RET_EXCPT
> + 0b001000 COND_DIR
> + 0b100001 DEBUG_HALT
> + 0b100010 CALL
> + 0b100011 TRAP
> + 0b100100 SERROR
> + 0b100110 INST_DEBUG
> + 0b100111 DATA_DEBUG
> + 0b101010 ALGN_FAULT
> + 0b101011 INST_FAULT
> + 0b101100 DATA_FAULT
> + 0b101110 IRQ
> + 0b101111 FIQ
> + 0b111001 DEBUG_EXIT
> +EndEnum
Same comments as for BRBINFx_EL1.TYPE
> +Enum 7:0 NUMREC
> + 0b1000 8
> + 0b10000 16
> + 0b100000 32
> + 0b1000000 64
Could we please pad these to the same width, i.e. have
0b0001000 8
0b0010000 16
0b0100000 32
0b1000000 64
That way it's much easier to see how these compare to one another, and it
matches the usual style.
Otherwise, I see the ARM ARM lists these in hex, and using that would also be
fine, e.g.
0x08 8
0x10 16
0x20 32
0x40 64
> +EndEnum
> +EndSysreg
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, will@kernel.org,
catalin.marinas@arm.com, Mark Brown <broonie@kernel.org>,
James Clark <james.clark@arm.com>, Rob Herring <robh@kernel.org>,
Marc Zyngier <maz@kernel.org>,
Suzuki Poulose <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH V11 02/10] arm64/perf: Add BRBE registers and fields
Date: Mon, 5 Jun 2023 08:55:27 +0100 [thread overview]
Message-ID: <ZH2U79ZP7HXNJctA@FVFF77S0Q05N> (raw)
In-Reply-To: <20230531040428.501523-3-anshuman.khandual@arm.com>
Hi ANshuman,
This looks good to me, with some minor nits on enum value naming and field
formatting.
On Wed, May 31, 2023 at 09:34:20AM +0530, Anshuman Khandual wrote:
> This adds BRBE related register definitions and various other related field
> macros there in. These will be used subsequently in a BRBE driver which is
> being added later on.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Tested-by: James Clark <james.clark@arm.com>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 103 +++++++++++++++++++++
> arch/arm64/tools/sysreg | 159 ++++++++++++++++++++++++++++++++
> 2 files changed, 262 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index e72d9aaab6b1..12419c55d3b7 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -165,6 +165,109 @@
> #define SYS_DBGDTRTX_EL0 sys_reg(2, 3, 0, 5, 0)
> #define SYS_DBGVCR32_EL2 sys_reg(2, 4, 0, 7, 0)
>
> +#define __SYS_BRBINFO(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 0))
> +#define __SYS_BRBSRC(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 1))
> +#define __SYS_BRBTGT(n) sys_reg(2, 1, 8, ((n) & 0xf), ((((n) & 0x10)) >> 2 + 2))
These look correct to me per ARM DDI 0487J.a
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index c9a0d1fa3209..44745f42262f 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -947,6 +947,165 @@ UnsignedEnum 3:0 BT
> EndEnum
> EndSysreg
>
> +
> +SysregFields BRBINFx_EL1
> +Res0 63:47
> +Field 46 CCU
> +Field 45:32 CC
> +Res0 31:18
> +Field 17 LASTFAILED
> +Field 16 T
> +Res0 15:14
> +Enum 13:8 TYPE
> + 0b000000 UNCOND_DIR
> + 0b000001 INDIR
> + 0b000010 DIR_LINK
> + 0b000011 INDIR_LINK
For clarity, I'd prefer that we use "DIRECT" and "INDIRECT" in full for each of
these, i.e.
0b000000 UNCOND_DIRECT
0b000001 INDIRECT
0b000010 DIRECT_LINK
0b000011 INDIRECT_LINK
> + 0b000101 RET_SUB
> + 0b000111 RET_EXCPT
Similarly, I'm not keen on the suffixes here.
I think these would be clearer as "RET" and "ERET", as those are short and
unambiguous, and I think the alternative of spelling out "RET_SUBROUTINE" and
"RET_EXCEPTION" is overly verbose.
> + 0b001000 COND_DIR
As with above, I'd prefer "COND_DIRECT" here.
> + 0b100001 DEBUG_HALT
> + 0b100010 CALL
> + 0b100011 TRAP
> + 0b100100 SERROR
> + 0b100110 INST_DEBUG
We generally use 'insn' rather than 'inst', so I'd prefer s/INST/INSN/ here.
> + 0b100111 DATA_DEBUG
> + 0b101010 ALGN_FAULT
s/ALGN/ALIGN/
> + 0b101011 INST_FAULT
As above, I'd prefer "INSN_FAULT" here, though I'm confused that the
architecture doesn't use "abort" naming for this.
> + 0b101100 DATA_FAULT
> + 0b101110 IRQ
> + 0b101111 FIQ
> + 0b111001 DEBUG_EXIT
> +EndEnum
[...]
+Sysreg BRBCR_EL1 2 1 9 0 0
> +Res0 63:24
> +Field 23 EXCEPTION
> +Field 22 ERTN
> +Res0 21:9
> +Field 8 FZP
> +Res0 7
> +Enum 6:5 TS
> + 0b01 VIRTUAL
> + 0b10 GST_PHYSICAL
s/GST/GUEST/
> + 0b11 PHYSICAL
> +EndEnum
> +Field 4 MPRED
> +Field 3 CC
> +Res0 2
> +Field 1 E1BRE
> +Field 0 E0BRE
> +EndSysreg
[...]
> +Sysreg BRBINFINJ_EL1 2 1 9 1 0
> +Res0 63:47
> +Field 46 CCU
> +Field 45:32 CC
> +Res0 31:18
> +Field 17 LASTFAILED
> +Field 16 T
> +Res0 15:14
> +Enum 13:8 TYPE
> + 0b000000 UNCOND_DIR
> + 0b000001 INDIR
> + 0b000010 DIR_LINK
> + 0b000011 INDIR_LINK
> + 0b000100 RET_SUB
> + 0b000100 RET_SUB
> + 0b000111 RET_EXCPT
> + 0b001000 COND_DIR
> + 0b100001 DEBUG_HALT
> + 0b100010 CALL
> + 0b100011 TRAP
> + 0b100100 SERROR
> + 0b100110 INST_DEBUG
> + 0b100111 DATA_DEBUG
> + 0b101010 ALGN_FAULT
> + 0b101011 INST_FAULT
> + 0b101100 DATA_FAULT
> + 0b101110 IRQ
> + 0b101111 FIQ
> + 0b111001 DEBUG_EXIT
> +EndEnum
Same comments as for BRBINFx_EL1.TYPE
> +Enum 7:0 NUMREC
> + 0b1000 8
> + 0b10000 16
> + 0b100000 32
> + 0b1000000 64
Could we please pad these to the same width, i.e. have
0b0001000 8
0b0010000 16
0b0100000 32
0b1000000 64
That way it's much easier to see how these compare to one another, and it
matches the usual style.
Otherwise, I see the ARM ARM lists these in hex, and using that would also be
fine, e.g.
0x08 8
0x10 16
0x20 32
0x40 64
> +EndEnum
> +EndSysreg
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-06-05 7:56 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 4:04 [PATCH V11 00/10] arm64/perf: Enable branch stack sampling Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 01/10] drivers: perf: arm_pmu: Add new sched_task() callback Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-05 7:26 ` Mark Rutland
2023-06-05 7:26 ` Mark Rutland
2023-05-31 4:04 ` [PATCH V11 02/10] arm64/perf: Add BRBE registers and fields Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-05 7:55 ` Mark Rutland [this message]
2023-06-05 7:55 ` Mark Rutland
2023-06-06 4:27 ` Anshuman Khandual
2023-06-06 4:27 ` Anshuman Khandual
2023-06-13 16:27 ` Mark Rutland
2023-06-13 16:27 ` Mark Rutland
2023-06-14 2:59 ` Anshuman Khandual
2023-06-14 2:59 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 03/10] arm64/perf: Add branch stack support in struct arm_pmu Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-05 7:58 ` Mark Rutland
2023-06-05 7:58 ` Mark Rutland
2023-06-06 4:47 ` Anshuman Khandual
2023-06-06 4:47 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 04/10] arm64/perf: Add branch stack support in struct pmu_hw_events Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-05 8:00 ` Mark Rutland
2023-06-05 8:00 ` Mark Rutland
2023-05-31 4:04 ` [PATCH V11 05/10] arm64/perf: Add branch stack support in ARMV8 PMU Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-02 2:33 ` Namhyung Kim
2023-06-02 2:33 ` Namhyung Kim
2023-06-05 2:43 ` Anshuman Khandual
2023-06-05 2:43 ` Anshuman Khandual
2023-06-05 12:05 ` Mark Rutland
2023-06-05 12:05 ` Mark Rutland
2023-06-06 10:34 ` Anshuman Khandual
2023-06-06 10:34 ` Anshuman Khandual
2023-06-06 10:41 ` Mark Rutland
2023-06-06 10:41 ` Mark Rutland
2023-06-08 10:13 ` Suzuki K Poulose
2023-06-08 10:13 ` Suzuki K Poulose
2023-06-09 4:00 ` Anshuman Khandual
2023-06-09 4:00 ` Anshuman Khandual
2023-06-09 9:54 ` Suzuki K Poulose
2023-06-09 9:54 ` Suzuki K Poulose
2023-06-09 7:14 ` Anshuman Khandual
2023-06-09 7:14 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 06/10] arm64/perf: Enable branch stack events via FEAT_BRBE Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-02 1:45 ` Namhyung Kim
2023-06-02 1:45 ` Namhyung Kim
2023-06-05 3:00 ` Anshuman Khandual
2023-06-05 3:00 ` Anshuman Khandual
2023-06-05 13:43 ` Mark Rutland
2023-06-05 13:43 ` Mark Rutland
2023-06-09 4:30 ` Anshuman Khandual
2023-06-09 4:30 ` Anshuman Khandual
2023-06-09 12:37 ` Mark Rutland
2023-06-09 12:37 ` Mark Rutland
2023-06-09 4:47 ` Anshuman Khandual
2023-06-09 4:47 ` Anshuman Khandual
2023-06-09 12:42 ` Mark Rutland
2023-06-09 12:42 ` Mark Rutland
2023-06-09 5:22 ` Anshuman Khandual
2023-06-09 5:22 ` Anshuman Khandual
2023-06-09 12:47 ` Mark Rutland
2023-06-09 12:47 ` Mark Rutland
2023-06-09 13:15 ` Mark Rutland
2023-06-09 13:15 ` Mark Rutland
2023-06-12 8:35 ` Anshuman Khandual
2023-06-09 13:34 ` James Clark
2023-06-09 13:34 ` James Clark
2023-06-12 10:12 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 07/10] arm64/perf: Add PERF_ATTACH_TASK_DATA to events with has_branch_stack() Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 08/10] arm64/perf: Add struct brbe_regset helper functions Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-02 2:40 ` Namhyung Kim
2023-06-02 2:40 ` Namhyung Kim
2023-06-05 3:14 ` Anshuman Khandual
2023-06-05 3:14 ` Anshuman Khandual
2023-06-05 23:49 ` Namhyung Kim
2023-06-05 23:49 ` Namhyung Kim
2023-06-13 17:17 ` Mark Rutland
2023-06-13 17:17 ` Mark Rutland
2023-06-14 5:14 ` Anshuman Khandual
2023-06-14 5:14 ` Anshuman Khandual
2023-06-14 10:59 ` Mark Rutland
2023-06-14 10:59 ` Mark Rutland
2023-05-31 4:04 ` [PATCH V11 09/10] arm64/perf: Implement branch records save on task sched out Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-05-31 4:04 ` [PATCH V11 10/10] arm64/perf: Implement branch records save on PMU IRQ Anshuman Khandual
2023-05-31 4:04 ` Anshuman Khandual
2023-06-09 11:13 ` [PATCH V11 00/10] arm64/perf: Enable branch stack sampling Anshuman Khandual
2023-06-09 11:13 ` Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH2U79ZP7HXNJctA@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=acme@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.clark@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.