* [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
@ 2024-02-23 11:31 Anshuman Khandual
2024-02-23 12:52 ` Will Deacon
0 siblings, 1 reply; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-23 11:31 UTC (permalink / raw)
To: linux-arm-kernel
Cc: broonie, Anshuman Khandual, Will Deacon, Mark Rutland,
Catalin Marinas, linux-kernel
Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
macros are used interchangeably to convert event->attr.bp_len and platform
breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
deriving one from the other. This does not cause any functional changes.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
This applies on v6.8-rc5
arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 35225632d70a..1ab9fc865ddd 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
switch (hbp_len) {
case ARM_BREAKPOINT_LEN_1:
- len_in_bytes = 1;
+ len_in_bytes = HW_BREAKPOINT_LEN_1;
break;
case ARM_BREAKPOINT_LEN_2:
- len_in_bytes = 2;
+ len_in_bytes = HW_BREAKPOINT_LEN_2;
break;
case ARM_BREAKPOINT_LEN_3:
- len_in_bytes = 3;
+ len_in_bytes = HW_BREAKPOINT_LEN_3;
break;
case ARM_BREAKPOINT_LEN_4:
- len_in_bytes = 4;
+ len_in_bytes = HW_BREAKPOINT_LEN_4;
break;
case ARM_BREAKPOINT_LEN_5:
- len_in_bytes = 5;
+ len_in_bytes = HW_BREAKPOINT_LEN_5;
break;
case ARM_BREAKPOINT_LEN_6:
- len_in_bytes = 6;
+ len_in_bytes = HW_BREAKPOINT_LEN_6;
break;
case ARM_BREAKPOINT_LEN_7:
- len_in_bytes = 7;
+ len_in_bytes = HW_BREAKPOINT_LEN_7;
break;
case ARM_BREAKPOINT_LEN_8:
- len_in_bytes = 8;
+ len_in_bytes = HW_BREAKPOINT_LEN_8;
break;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-23 11:31 [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Anshuman Khandual
@ 2024-02-23 12:52 ` Will Deacon
2024-02-26 2:49 ` Anshuman Khandual
0 siblings, 1 reply; 9+ messages in thread
From: Will Deacon @ 2024-02-23 12:52 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, broonie, Mark Rutland, Catalin Marinas, linux-kernel
On Fri, Feb 23, 2024 at 05:01:02PM +0530, Anshuman Khandual wrote:
> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
> macros are used interchangeably to convert event->attr.bp_len and platform
> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
> deriving one from the other. This does not cause any functional changes.
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This applies on v6.8-rc5
>
> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index 35225632d70a..1ab9fc865ddd 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
>
> switch (hbp_len) {
> case ARM_BREAKPOINT_LEN_1:
> - len_in_bytes = 1;
> + len_in_bytes = HW_BREAKPOINT_LEN_1;
I don't think we should do this. The HW_BREAKPOINT_LEN_* definitions are
part of the user ABI and, although they correspond to the length in bytes,
that's not necessarily something we should rely on.
Will
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-23 12:52 ` Will Deacon
@ 2024-02-26 2:49 ` Anshuman Khandual
2024-02-26 11:04 ` Mark Rutland
0 siblings, 1 reply; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-26 2:49 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, broonie, Mark Rutland, Catalin Marinas, linux-kernel
On 2/23/24 18:22, Will Deacon wrote:
> On Fri, Feb 23, 2024 at 05:01:02PM +0530, Anshuman Khandual wrote:
>> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
>> macros are used interchangeably to convert event->attr.bp_len and platform
>> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
>> deriving one from the other. This does not cause any functional changes.
>>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> This applies on v6.8-rc5
>>
>> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
>> index 35225632d70a..1ab9fc865ddd 100644
>> --- a/arch/arm64/kernel/hw_breakpoint.c
>> +++ b/arch/arm64/kernel/hw_breakpoint.c
>> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
>>
>> switch (hbp_len) {
>> case ARM_BREAKPOINT_LEN_1:
>> - len_in_bytes = 1;
>> + len_in_bytes = HW_BREAKPOINT_LEN_1;
>
> I don't think we should do this. The HW_BREAKPOINT_LEN_* definitions are
> part of the user ABI and, although they correspond to the length in bytes,
> that's not necessarily something we should rely on.
Why should not we rely on the user ABI macros if these byte lengths were
initially derived from them. But also there are similar conversions in
arch_bp_generic_fields(). These hard coded raw byte length numbers seems
cryptic, where as in reality these are just inter converted from generic
HW breakpoints lengths.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-26 2:49 ` Anshuman Khandual
@ 2024-02-26 11:04 ` Mark Rutland
2024-02-27 5:31 ` Anshuman Khandual
0 siblings, 1 reply; 9+ messages in thread
From: Mark Rutland @ 2024-02-26 11:04 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Will Deacon, linux-arm-kernel, broonie, Catalin Marinas, linux-kernel
On Mon, Feb 26, 2024 at 08:19:39AM +0530, Anshuman Khandual wrote:
> On 2/23/24 18:22, Will Deacon wrote:
> > On Fri, Feb 23, 2024 at 05:01:02PM +0530, Anshuman Khandual wrote:
> >> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
> >> macros are used interchangeably to convert event->attr.bp_len and platform
> >> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
> >> deriving one from the other. This does not cause any functional changes.
> >>
> >> Cc: Will Deacon <will@kernel.org>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> >> ---
> >> This applies on v6.8-rc5
> >>
> >> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
> >> 1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> >> index 35225632d70a..1ab9fc865ddd 100644
> >> --- a/arch/arm64/kernel/hw_breakpoint.c
> >> +++ b/arch/arm64/kernel/hw_breakpoint.c
> >> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
> >>
> >> switch (hbp_len) {
> >> case ARM_BREAKPOINT_LEN_1:
> >> - len_in_bytes = 1;
> >> + len_in_bytes = HW_BREAKPOINT_LEN_1;
> >
> > I don't think we should do this. The HW_BREAKPOINT_LEN_* definitions are
> > part of the user ABI and, although they correspond to the length in bytes,
> > that's not necessarily something we should rely on.
>
> Why should not we rely on the user ABI macros if these byte lengths were
> initially derived from them.
Why should we change the clear:
len_in_bytes = 1;
... to the longer, and less clear:
len_in_bytes = HW_BREAKPOINT_LEN_1;
... ?
> But also there are similar conversions in arch_bp_generic_fields().
Those are specifically for converting from the rch_hw_breakpoint_ctrl encodings
to the perf_event_attr encodings. There we don't care about the specific value
of the byte, just that we're using the correct encoding.
> These hard coded raw byte length numbers seems cryptic, where as in reality
> these are just inter converted from generic HW breakpoints lengths.
There are three distinct concepts here:
1. The length in bytes, as returned above by get_hbp_len()
2. The length as encoded in the ARM_BREAKPOINT_LEN_* encoding
3. The length as encoded in the HW_BREAKPOINT_LEN_* encoding.
I think you're arguing that since 1 and 3 happen to have the values we should
treat them as the same thing. I think that Will and I believe that they should
be kept distinct because they are distinct concepts.
I don't think this needs to change, and can be left as-is.
Mark.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-26 11:04 ` Mark Rutland
@ 2024-02-27 5:31 ` Anshuman Khandual
2024-02-27 9:05 ` Will Deacon
0 siblings, 1 reply; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-27 5:31 UTC (permalink / raw)
To: Mark Rutland
Cc: Will Deacon, linux-arm-kernel, broonie, Catalin Marinas, linux-kernel
On 2/26/24 16:34, Mark Rutland wrote:
> On Mon, Feb 26, 2024 at 08:19:39AM +0530, Anshuman Khandual wrote:
>> On 2/23/24 18:22, Will Deacon wrote:
>>> On Fri, Feb 23, 2024 at 05:01:02PM +0530, Anshuman Khandual wrote:
>>>> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
>>>> macros are used interchangeably to convert event->attr.bp_len and platform
>>>> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
>>>> deriving one from the other. This does not cause any functional changes.
>>>>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> ---
>>>> This applies on v6.8-rc5
>>>>
>>>> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
>>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
>>>> index 35225632d70a..1ab9fc865ddd 100644
>>>> --- a/arch/arm64/kernel/hw_breakpoint.c
>>>> +++ b/arch/arm64/kernel/hw_breakpoint.c
>>>> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
>>>>
>>>> switch (hbp_len) {
>>>> case ARM_BREAKPOINT_LEN_1:
>>>> - len_in_bytes = 1;
>>>> + len_in_bytes = HW_BREAKPOINT_LEN_1;
>>>
>>> I don't think we should do this. The HW_BREAKPOINT_LEN_* definitions are
>>> part of the user ABI and, although they correspond to the length in bytes,
>>> that's not necessarily something we should rely on.
>>
>> Why should not we rely on the user ABI macros if these byte lengths were
>> initially derived from them.
>
> Why should we change the clear:
>
> len_in_bytes = 1;
>
> ... to the longer, and less clear:
>
> len_in_bytes = HW_BREAKPOINT_LEN_1;
>
> ... ?
>
>> But also there are similar conversions in arch_bp_generic_fields().
>
> Those are specifically for converting from the rch_hw_breakpoint_ctrl encodings
> to the perf_event_attr encodings. There we don't care about the specific value
> of the byte, just that we're using the correct encoding.
>
>> These hard coded raw byte length numbers seems cryptic, where as in reality
>> these are just inter converted from generic HW breakpoints lengths.
>
> There are three distinct concepts here:
>
> 1. The length in bytes, as returned above by get_hbp_len()
>
> 2. The length as encoded in the ARM_BREAKPOINT_LEN_* encoding
>
> 3. The length as encoded in the HW_BREAKPOINT_LEN_* encoding.
>
> I think you're arguing that since 1 and 3 happen to have the values we should
> treat them as the same thing. I think that Will and I believe that they should
> be kept distinct because they are distinct concepts.
>
> I don't think this needs to change, and can be left as-is.
Fair enough, but just wondering how about deriving len_in_bytes from
hweight_long(ARM_BREAKPOINT_LEN_*) instead ? This also drops the hard
coding using the platform macros itself, without going to user ABI.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-27 5:31 ` Anshuman Khandual
@ 2024-02-27 9:05 ` Will Deacon
2024-02-27 9:39 ` Anshuman Khandual
0 siblings, 1 reply; 9+ messages in thread
From: Will Deacon @ 2024-02-27 9:05 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-arm-kernel, broonie, Catalin Marinas, linux-kernel
On Tue, Feb 27, 2024 at 11:01:54AM +0530, Anshuman Khandual wrote:
> On 2/26/24 16:34, Mark Rutland wrote:
> > I don't think this needs to change, and can be left as-is.
>
> Fair enough, but just wondering how about deriving len_in_bytes from
> hweight_long(ARM_BREAKPOINT_LEN_*) instead ? This also drops the hard
> coding using the platform macros itself, without going to user ABI.
Please leave this code alone. It's fine like it is and there are plenty of
other things that would actually benefit from your attention. The BRBE
series, for example.
Will
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-27 9:05 ` Will Deacon
@ 2024-02-27 9:39 ` Anshuman Khandual
0 siblings, 0 replies; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-27 9:39 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, linux-arm-kernel, broonie, Catalin Marinas, linux-kernel
On 2/27/24 14:35, Will Deacon wrote:
> On Tue, Feb 27, 2024 at 11:01:54AM +0530, Anshuman Khandual wrote:
>> On 2/26/24 16:34, Mark Rutland wrote:
>>> I don't think this needs to change, and can be left as-is.
>>
>> Fair enough, but just wondering how about deriving len_in_bytes from
>> hweight_long(ARM_BREAKPOINT_LEN_*) instead ? This also drops the hard
>> coding using the platform macros itself, without going to user ABI.
>
> Please leave this code alone. It's fine like it is and there are plenty of
> other things that would actually benefit from your attention. The BRBE
> series, for example.
Sure, no problem, will drop this patch.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH V16 1/8] arm64/sysreg: Add BRBE registers and fields
@ 2024-01-25 9:41 Anshuman Khandual
2024-02-26 4:22 ` [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Anshuman Khandual
0 siblings, 1 reply; 9+ messages in thread
From: Anshuman Khandual @ 2024-01-25 9:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, will, catalin.marinas, mark.rutland
Cc: Anshuman Khandual, Mark Brown, James Clark, Rob Herring,
Marc Zyngier, Suzuki Poulose, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, linux-perf-users
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
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
Changes in V16:
- Updated BRBINFx_EL1.TYPE = 0b110000 as field IMPDEF_TRAP_EL3
- Updated BRBCR_ELx[9] as field FZPSS
- Updated BRBINFINJ_EL1 to use sysreg field BRBINFx_EL1
arch/arm64/include/asm/sysreg.h | 109 ++++++++++++++++++++++++++
arch/arm64/tools/sysreg | 131 ++++++++++++++++++++++++++++++++
2 files changed, 240 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index c3b19b376c86..72544b5c4951 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -272,6 +272,109 @@
#define SYS_BRBCR_EL2 sys_reg(2, 4, 9, 0, 0)
+#define __SYS_BRBINF(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))
+
+#define SYS_BRBINF0_EL1 __SYS_BRBINF(0)
+#define SYS_BRBINF1_EL1 __SYS_BRBINF(1)
+#define SYS_BRBINF2_EL1 __SYS_BRBINF(2)
+#define SYS_BRBINF3_EL1 __SYS_BRBINF(3)
+#define SYS_BRBINF4_EL1 __SYS_BRBINF(4)
+#define SYS_BRBINF5_EL1 __SYS_BRBINF(5)
+#define SYS_BRBINF6_EL1 __SYS_BRBINF(6)
+#define SYS_BRBINF7_EL1 __SYS_BRBINF(7)
+#define SYS_BRBINF8_EL1 __SYS_BRBINF(8)
+#define SYS_BRBINF9_EL1 __SYS_BRBINF(9)
+#define SYS_BRBINF10_EL1 __SYS_BRBINF(10)
+#define SYS_BRBINF11_EL1 __SYS_BRBINF(11)
+#define SYS_BRBINF12_EL1 __SYS_BRBINF(12)
+#define SYS_BRBINF13_EL1 __SYS_BRBINF(13)
+#define SYS_BRBINF14_EL1 __SYS_BRBINF(14)
+#define SYS_BRBINF15_EL1 __SYS_BRBINF(15)
+#define SYS_BRBINF16_EL1 __SYS_BRBINF(16)
+#define SYS_BRBINF17_EL1 __SYS_BRBINF(17)
+#define SYS_BRBINF18_EL1 __SYS_BRBINF(18)
+#define SYS_BRBINF19_EL1 __SYS_BRBINF(19)
+#define SYS_BRBINF20_EL1 __SYS_BRBINF(20)
+#define SYS_BRBINF21_EL1 __SYS_BRBINF(21)
+#define SYS_BRBINF22_EL1 __SYS_BRBINF(22)
+#define SYS_BRBINF23_EL1 __SYS_BRBINF(23)
+#define SYS_BRBINF24_EL1 __SYS_BRBINF(24)
+#define SYS_BRBINF25_EL1 __SYS_BRBINF(25)
+#define SYS_BRBINF26_EL1 __SYS_BRBINF(26)
+#define SYS_BRBINF27_EL1 __SYS_BRBINF(27)
+#define SYS_BRBINF28_EL1 __SYS_BRBINF(28)
+#define SYS_BRBINF29_EL1 __SYS_BRBINF(29)
+#define SYS_BRBINF30_EL1 __SYS_BRBINF(30)
+#define SYS_BRBINF31_EL1 __SYS_BRBINF(31)
+
+#define SYS_BRBSRC0_EL1 __SYS_BRBSRC(0)
+#define SYS_BRBSRC1_EL1 __SYS_BRBSRC(1)
+#define SYS_BRBSRC2_EL1 __SYS_BRBSRC(2)
+#define SYS_BRBSRC3_EL1 __SYS_BRBSRC(3)
+#define SYS_BRBSRC4_EL1 __SYS_BRBSRC(4)
+#define SYS_BRBSRC5_EL1 __SYS_BRBSRC(5)
+#define SYS_BRBSRC6_EL1 __SYS_BRBSRC(6)
+#define SYS_BRBSRC7_EL1 __SYS_BRBSRC(7)
+#define SYS_BRBSRC8_EL1 __SYS_BRBSRC(8)
+#define SYS_BRBSRC9_EL1 __SYS_BRBSRC(9)
+#define SYS_BRBSRC10_EL1 __SYS_BRBSRC(10)
+#define SYS_BRBSRC11_EL1 __SYS_BRBSRC(11)
+#define SYS_BRBSRC12_EL1 __SYS_BRBSRC(12)
+#define SYS_BRBSRC13_EL1 __SYS_BRBSRC(13)
+#define SYS_BRBSRC14_EL1 __SYS_BRBSRC(14)
+#define SYS_BRBSRC15_EL1 __SYS_BRBSRC(15)
+#define SYS_BRBSRC16_EL1 __SYS_BRBSRC(16)
+#define SYS_BRBSRC17_EL1 __SYS_BRBSRC(17)
+#define SYS_BRBSRC18_EL1 __SYS_BRBSRC(18)
+#define SYS_BRBSRC19_EL1 __SYS_BRBSRC(19)
+#define SYS_BRBSRC20_EL1 __SYS_BRBSRC(20)
+#define SYS_BRBSRC21_EL1 __SYS_BRBSRC(21)
+#define SYS_BRBSRC22_EL1 __SYS_BRBSRC(22)
+#define SYS_BRBSRC23_EL1 __SYS_BRBSRC(23)
+#define SYS_BRBSRC24_EL1 __SYS_BRBSRC(24)
+#define SYS_BRBSRC25_EL1 __SYS_BRBSRC(25)
+#define SYS_BRBSRC26_EL1 __SYS_BRBSRC(26)
+#define SYS_BRBSRC27_EL1 __SYS_BRBSRC(27)
+#define SYS_BRBSRC28_EL1 __SYS_BRBSRC(28)
+#define SYS_BRBSRC29_EL1 __SYS_BRBSRC(29)
+#define SYS_BRBSRC30_EL1 __SYS_BRBSRC(30)
+#define SYS_BRBSRC31_EL1 __SYS_BRBSRC(31)
+
+#define SYS_BRBTGT0_EL1 __SYS_BRBTGT(0)
+#define SYS_BRBTGT1_EL1 __SYS_BRBTGT(1)
+#define SYS_BRBTGT2_EL1 __SYS_BRBTGT(2)
+#define SYS_BRBTGT3_EL1 __SYS_BRBTGT(3)
+#define SYS_BRBTGT4_EL1 __SYS_BRBTGT(4)
+#define SYS_BRBTGT5_EL1 __SYS_BRBTGT(5)
+#define SYS_BRBTGT6_EL1 __SYS_BRBTGT(6)
+#define SYS_BRBTGT7_EL1 __SYS_BRBTGT(7)
+#define SYS_BRBTGT8_EL1 __SYS_BRBTGT(8)
+#define SYS_BRBTGT9_EL1 __SYS_BRBTGT(9)
+#define SYS_BRBTGT10_EL1 __SYS_BRBTGT(10)
+#define SYS_BRBTGT11_EL1 __SYS_BRBTGT(11)
+#define SYS_BRBTGT12_EL1 __SYS_BRBTGT(12)
+#define SYS_BRBTGT13_EL1 __SYS_BRBTGT(13)
+#define SYS_BRBTGT14_EL1 __SYS_BRBTGT(14)
+#define SYS_BRBTGT15_EL1 __SYS_BRBTGT(15)
+#define SYS_BRBTGT16_EL1 __SYS_BRBTGT(16)
+#define SYS_BRBTGT17_EL1 __SYS_BRBTGT(17)
+#define SYS_BRBTGT18_EL1 __SYS_BRBTGT(18)
+#define SYS_BRBTGT19_EL1 __SYS_BRBTGT(19)
+#define SYS_BRBTGT20_EL1 __SYS_BRBTGT(20)
+#define SYS_BRBTGT21_EL1 __SYS_BRBTGT(21)
+#define SYS_BRBTGT22_EL1 __SYS_BRBTGT(22)
+#define SYS_BRBTGT23_EL1 __SYS_BRBTGT(23)
+#define SYS_BRBTGT24_EL1 __SYS_BRBTGT(24)
+#define SYS_BRBTGT25_EL1 __SYS_BRBTGT(25)
+#define SYS_BRBTGT26_EL1 __SYS_BRBTGT(26)
+#define SYS_BRBTGT27_EL1 __SYS_BRBTGT(27)
+#define SYS_BRBTGT28_EL1 __SYS_BRBTGT(28)
+#define SYS_BRBTGT29_EL1 __SYS_BRBTGT(29)
+#define SYS_BRBTGT30_EL1 __SYS_BRBTGT(30)
+#define SYS_BRBTGT31_EL1 __SYS_BRBTGT(31)
+
#define SYS_MIDR_EL1 sys_reg(3, 0, 0, 0, 0)
#define SYS_MPIDR_EL1 sys_reg(3, 0, 0, 0, 5)
#define SYS_REVIDR_EL1 sys_reg(3, 0, 0, 0, 6)
@@ -794,6 +897,12 @@
#define OP_COSP_RCTX sys_insn(1, 3, 7, 3, 6)
#define OP_CPP_RCTX sys_insn(1, 3, 7, 3, 7)
+/*
+ * BRBE Instructions
+ */
+#define BRB_IALL_INSN __emit_inst(0xd5000000 | OP_BRB_IALL | (0x1f))
+#define BRB_INJ_INSN __emit_inst(0xd5000000 | OP_BRB_INJ | (0x1f))
+
/* Common SCTLR_ELx flags. */
#define SCTLR_ELx_ENTP2 (BIT(60))
#define SCTLR_ELx_DSSBS (BIT(44))
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 4c9b67934367..caf851ba5dc0 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1023,6 +1023,137 @@ UnsignedEnum 3:0 MTEPERM
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_DIRECT
+ 0b000001 INDIRECT
+ 0b000010 DIRECT_LINK
+ 0b000011 INDIRECT_LINK
+ 0b000101 RET
+ 0b000111 ERET
+ 0b001000 COND_DIRECT
+ 0b100001 DEBUG_HALT
+ 0b100010 CALL
+ 0b100011 TRAP
+ 0b100100 SERROR
+ 0b100110 INSN_DEBUG
+ 0b100111 DATA_DEBUG
+ 0b101010 ALIGN_FAULT
+ 0b101011 INSN_FAULT
+ 0b101100 DATA_FAULT
+ 0b101110 IRQ
+ 0b101111 FIQ
+ 0b110000 IMPDEF_TRAP_EL3
+ 0b111001 DEBUG_EXIT
+EndEnum
+Enum 7:6 EL
+ 0b00 EL0
+ 0b01 EL1
+ 0b10 EL2
+ 0b11 EL3
+EndEnum
+Field 5 MPRED
+Res0 4:2
+Enum 1:0 VALID
+ 0b00 NONE
+ 0b01 TARGET
+ 0b10 SOURCE
+ 0b11 FULL
+EndEnum
+EndSysregFields
+
+SysregFields BRBCR_ELx
+Res0 63:24
+Field 23 EXCEPTION
+Field 22 ERTN
+Res0 21:10
+Field 9 FZPSS
+Field 8 FZP
+Res0 7
+Enum 6:5 TS
+ 0b01 VIRTUAL
+ 0b10 GUEST_PHYSICAL
+ 0b11 PHYSICAL
+EndEnum
+Field 4 MPRED
+Field 3 CC
+Res0 2
+Field 1 ExBRE
+Field 0 E0BRE
+EndSysregFields
+
+Sysreg BRBCR_EL2 2 4 9 0 0
+Fields BRBCR_ELx
+EndSysreg
+
+Sysreg BRBCR_EL1 2 1 9 0 0
+Fields BRBCR_ELx
+EndSysreg
+
+Sysreg BRBCR_EL12 2 5 9 0 0
+Fields BRBCR_ELx
+EndSysreg
+
+Sysreg BRBFCR_EL1 2 1 9 0 1
+Res0 63:30
+Enum 29:28 BANK
+ 0b0 FIRST
+ 0b1 SECOND
+EndEnum
+Res0 27:23
+Field 22 CONDDIR
+Field 21 DIRCALL
+Field 20 INDCALL
+Field 19 RTN
+Field 18 INDIRECT
+Field 17 DIRECT
+Field 16 EnI
+Res0 15:8
+Field 7 PAUSED
+Field 6 LASTFAILED
+Res0 5:0
+EndSysreg
+
+Sysreg BRBTS_EL1 2 1 9 0 2
+Field 63:0 TS
+EndSysreg
+
+Sysreg BRBINFINJ_EL1 2 1 9 1 0
+Fields BRBINFx_EL1
+EndSysreg
+
+Sysreg BRBSRCINJ_EL1 2 1 9 1 1
+Field 63:0 ADDRESS
+EndSysreg
+
+Sysreg BRBTGTINJ_EL1 2 1 9 1 2
+Field 63:0 ADDRESS
+EndSysreg
+
+Sysreg BRBIDR0_EL1 2 1 9 2 0
+Res0 63:16
+Enum 15:12 CC
+ 0b101 20_BIT
+EndEnum
+Enum 11:8 FORMAT
+ 0b0 0
+EndEnum
+Enum 7:0 NUMREC
+ 0b0001000 8
+ 0b0010000 16
+ 0b0100000 32
+ 0b1000000 64
+EndEnum
+EndSysreg
+
Sysreg ID_AA64ZFR0_EL1 3 0 0 4 4
Res0 63:60
UnsignedEnum 59:56 F64MM
--
2.25.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-01-25 9:41 [PATCH V16 1/8] arm64/sysreg: Add BRBE registers and fields Anshuman Khandual
@ 2024-02-26 4:22 ` Anshuman Khandual
2024-02-26 4:26 ` Anshuman Khandual
0 siblings, 1 reply; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-26 4:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: broonie, mark.rutland, Anshuman Khandual, Will Deacon,
Catalin Marinas, linux-kernel
Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
macros are used interchangeably to convert event->attr.bp_len and platform
breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
deriving one from the other. This does not cause any functional changes.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
This applies on v6.8-rc5
arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 35225632d70a..1ab9fc865ddd 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
switch (hbp_len) {
case ARM_BREAKPOINT_LEN_1:
- len_in_bytes = 1;
+ len_in_bytes = HW_BREAKPOINT_LEN_1;
break;
case ARM_BREAKPOINT_LEN_2:
- len_in_bytes = 2;
+ len_in_bytes = HW_BREAKPOINT_LEN_2;
break;
case ARM_BREAKPOINT_LEN_3:
- len_in_bytes = 3;
+ len_in_bytes = HW_BREAKPOINT_LEN_3;
break;
case ARM_BREAKPOINT_LEN_4:
- len_in_bytes = 4;
+ len_in_bytes = HW_BREAKPOINT_LEN_4;
break;
case ARM_BREAKPOINT_LEN_5:
- len_in_bytes = 5;
+ len_in_bytes = HW_BREAKPOINT_LEN_5;
break;
case ARM_BREAKPOINT_LEN_6:
- len_in_bytes = 6;
+ len_in_bytes = HW_BREAKPOINT_LEN_6;
break;
case ARM_BREAKPOINT_LEN_7:
- len_in_bytes = 7;
+ len_in_bytes = HW_BREAKPOINT_LEN_7;
break;
case ARM_BREAKPOINT_LEN_8:
- len_in_bytes = 8;
+ len_in_bytes = HW_BREAKPOINT_LEN_8;
break;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros
2024-02-26 4:22 ` [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Anshuman Khandual
@ 2024-02-26 4:26 ` Anshuman Khandual
0 siblings, 0 replies; 9+ messages in thread
From: Anshuman Khandual @ 2024-02-26 4:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: broonie, mark.rutland, Will Deacon, Catalin Marinas, linux-kernel
On 2/26/24 09:52, Anshuman Khandual wrote:
> Both platform i.e ARM_BREAKPOINT_LEN_X and generic i.e HW_BREAKPOINT_LEN_X
> macros are used interchangeably to convert event->attr.bp_len and platform
> breakpoint control arch_hw_breakpoint_ctrl->len. Let's be consistent while
> deriving one from the other. This does not cause any functional changes.
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This applies on v6.8-rc5
>
> arch/arm64/kernel/hw_breakpoint.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index 35225632d70a..1ab9fc865ddd 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -301,28 +301,28 @@ static int get_hbp_len(u8 hbp_len)
>
> switch (hbp_len) {
> case ARM_BREAKPOINT_LEN_1:
> - len_in_bytes = 1;
> + len_in_bytes = HW_BREAKPOINT_LEN_1;
> break;
> case ARM_BREAKPOINT_LEN_2:
> - len_in_bytes = 2;
> + len_in_bytes = HW_BREAKPOINT_LEN_2;
> break;
> case ARM_BREAKPOINT_LEN_3:
> - len_in_bytes = 3;
> + len_in_bytes = HW_BREAKPOINT_LEN_3;
> break;
> case ARM_BREAKPOINT_LEN_4:
> - len_in_bytes = 4;
> + len_in_bytes = HW_BREAKPOINT_LEN_4;
> break;
> case ARM_BREAKPOINT_LEN_5:
> - len_in_bytes = 5;
> + len_in_bytes = HW_BREAKPOINT_LEN_5;
> break;
> case ARM_BREAKPOINT_LEN_6:
> - len_in_bytes = 6;
> + len_in_bytes = HW_BREAKPOINT_LEN_6;
> break;
> case ARM_BREAKPOINT_LEN_7:
> - len_in_bytes = 7;
> + len_in_bytes = HW_BREAKPOINT_LEN_7;
> break;
> case ARM_BREAKPOINT_LEN_8:
> - len_in_bytes = 8;
> + len_in_bytes = HW_BREAKPOINT_LEN_8;
> break;
> }
>
Please ignore this. Wrong patch got picked up in the git send-email :)
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-02-27 9:39 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-23 11:31 [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Anshuman Khandual
2024-02-23 12:52 ` Will Deacon
2024-02-26 2:49 ` Anshuman Khandual
2024-02-26 11:04 ` Mark Rutland
2024-02-27 5:31 ` Anshuman Khandual
2024-02-27 9:05 ` Will Deacon
2024-02-27 9:39 ` Anshuman Khandual
-- strict thread matches above, loose matches on Subject: below --
2024-01-25 9:41 [PATCH V16 1/8] arm64/sysreg: Add BRBE registers and fields Anshuman Khandual
2024-02-26 4:22 ` [PATCH] arm64/hw_breakpoint: Determine lengths from generic perf breakpoint macros Anshuman Khandual
2024-02-26 4:26 ` Anshuman Khandual
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).