From: Ravi Bangoria <hidden> Date: 2020-07-17 04:10:57
Last series[1] was to add basic infrastructure support for more than
one watchpoint on Book3S powerpc. This series actually enables the 2nd
DAWR for baremetal and powervm. Kvm guest is still not supported.
v3: https://lore.kernel.org/lkml/20200708045046.135702-1-ravi.bangoria@linux.ibm.com
v3->v4:
- v3 patch #2 is split into two v4 patches: #2 and #3
- Few other minor neats suggested by Jordan Niethe
- Rebased to powerpc/next
[1]: https://lore.kernel.org/linuxppc-dev/20200514111741.97993-1-ravi.bangoria@linux.ibm.com/
Ravi Bangoria (10):
powerpc/watchpoint: Fix 512 byte boundary limit
powerpc/watchpoint: Fix DAWR exception constraint
powerpc/watchpoint: Fix DAWR exception for CACHEOP
powerpc/watchpoint: Enable watchpoint functionality on power10 guest
powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR
powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
powerpc/watchpoint: Guest support for 2nd DAWR hcall
powerpc/watchpoint: Return available watchpoints dynamically
powerpc/watchpoint: Remove 512 byte boundary
arch/powerpc/include/asm/cputable.h | 13 ++-
arch/powerpc/include/asm/hvcall.h | 3 +-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +-
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 7 +-
arch/powerpc/kernel/dawr.c | 2 +-
arch/powerpc/kernel/dt_cpu_ftrs.c | 7 ++
arch/powerpc/kernel/hw_breakpoint.c | 98 +++++++++++++++--------
arch/powerpc/kernel/prom.c | 2 +
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 7 +-
11 files changed, 101 insertions(+), 47 deletions(-)
--
2.26.2
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:10:59
Milton Miller reported that we are aligning start and end address to
wrong size SZ_512M. It should be SZ_512. Fix that.
While doing this change I also found a case where ALIGN() comparison
fails. Within a given aligned range, ALIGN() of two addresses does not
match when start address is pointing to the first byte and end address
is pointing to any other byte except the first one. But that's not true
for ALIGN_DOWN(). ALIGN_DOWN() of any two addresses within that range
will always point to the first byte. So use ALIGN_DOWN() instead of
ALIGN().
Fixes: e68ef121c1f4 ("powerpc/watchpoint: Use builtin ALIGN*() macros")
Reported-by: Milton Miller <redacted>
Signed-off-by: Ravi Bangoria <redacted>
Tested-by: Jordan Niethe <redacted>
---
arch/powerpc/kernel/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -419,7 +419,7 @@ static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)if(dawr_enabled()){max_len=DAWR_MAX_LEN;/* DAWR region can't cross 512 bytes boundary */-if(ALIGN(start_addr,SZ_512M)!=ALIGN(end_addr-1,SZ_512M))+if(ALIGN_DOWN(start_addr,SZ_512)!=ALIGN_DOWN(end_addr-1,SZ_512))return-EINVAL;}elseif(IS_ENABLED(CONFIG_PPC_8xx)){/* 8xx can setup a range without limitation */
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:12
Pedro Miraglia Franco de Carvalho noticed that on p8/p9, DAR value is
inconsistent with different type of load/store. Like for byte,word
etc. load/stores, DAR is set to the address of the first byte of
overlap between watch range and real access. But for quadword load/
store it's sometime set to the address of the first byte of real
access whereas sometime set to the address of the first byte of
overlap. This issue has been fixed in p10. In p10(ISA 3.1), DAR is
always set to the address of the first byte of overlap. Commit 27985b2a640e
("powerpc/watchpoint: Don't ignore extraneous exceptions blindly")
wrongly assumes that DAR is set to the address of the first byte of
overlap for all load/stores on p8/p9 as well. Fix that. With the fix,
we now rely on 'ea' provided by analyse_instr(). If analyse_instr()
fails, generate event unconditionally on p8/p9, and on p10 generate
event only if DAR is within a DAWR range.
Note: 8xx is not affected.
Fixes: 27985b2a640e ("powerpc/watchpoint: Don't ignore extraneous exceptions blindly")
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one watchpoint")
Reported-by: Pedro Miraglia Franco de Carvalho <redacted>
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/kernel/hw_breakpoint.c | 72 ++++++++++++++++-------------
1 file changed, 41 insertions(+), 31 deletions(-)
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:12
'ea' returned by analyse_instr() needs to be aligned down to cache
block size for CACHEOP instructions. analyse_instr() does not set
size for CACHEOP, thus size also needs to be calculated manually.
Fixes: 27985b2a640e ("powerpc/watchpoint: Don't ignore extraneous exceptions blindly")
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one watchpoint")
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/kernel/hw_breakpoint.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:14
CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
this change does not enable 2nd DAWR support.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:20
As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
DAWR is present, otherwise not. Host generally uses "cpu-features",
which masks "pa-features". But "cpu-features" are still not used for
guests and thus this change is mostly applicable for guests only.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/kernel/prom.c | 2 ++
1 file changed, 2 insertions(+)
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)staticinlinelongplpar_set_watchpoint0(unsignedlongdawr0,unsignedlongdawrx0){-returnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR,dawr0,dawrx0);+returnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR0,dawr0,dawrx0);}staticinlinelongplpar_signal_sys_reset(longcpu)
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:30
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:34
Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)if(dawr_enabled()){max_len=DAWR_MAX_LEN;-/* DAWR region can't cross 512 bytes boundary */-if(ALIGN_DOWN(start_addr,SZ_512)!=ALIGN_DOWN(end_addr-1,SZ_512))+/* DAWR region can't cross 512 bytes boundary on p10 predecessors */+if(!cpu_has_feature(CPU_FTR_ARCH_31)&&+(ALIGN_DOWN(start_addr,SZ_512)!=ALIGN_DOWN(end_addr-1,SZ_512)))return-EINVAL;}elseif(IS_ENABLED(CONFIG_PPC_8xx)){/* 8xx can setup a range without limitation */
From: Ravi Bangoria <hidden> Date: 2020-07-17 04:11:38
2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 5 +++++
arch/powerpc/kernel/dawr.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 7 +++++--
5 files changed, 13 insertions(+), 4 deletions(-)
@@ -131,7 +131,7 @@ struct machdep_calls {unsignedlongdabrx);/* Set DAWR for this platform, leave empty for default implementation */-int(*set_dawr)(unsignedlongdawr,+int(*set_dawr)(intnr,unsignedlongdawr,unsignedlongdawrx);#ifdef CONFIG_PPC32 /* XXX for now */
@@ -315,6 +315,11 @@ static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long dawrreturnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR0,dawr0,dawrx0);}+staticinlinelongplpar_set_watchpoint1(unsignedlongdawr1,unsignedlongdawrx1)+{+returnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR1,dawr1,dawrx1);+}+staticinlinelongplpar_signal_sys_reset(longcpu){returnplpar_hcall_norets(H_SIGNAL_SYS_RESET,cpu);
@@ -831,12 +831,15 @@ static int pseries_set_xdabr(unsigned long dabr, unsigned long dabrx)returnplpar_hcall_norets(H_SET_XDABR,dabr,dabrx);}-staticintpseries_set_dawr(unsignedlongdawr,unsignedlongdawrx)+staticintpseries_set_dawr(intnr,unsignedlongdawr,unsignedlongdawrx){/* PAPR says we can't set HYP */dawrx&=~DAWRX_HYP;-returnplpar_set_watchpoint0(dawr,dawrx);+if(nr==0)+returnplpar_set_watchpoint0(dawr,dawrx);+else+returnplpar_set_watchpoint1(dawr,dawrx);}#define CMO_CHARACTERISTICS_TOKEN 44
From: Jordan Niethe <hidden> Date: 2020-07-17 04:24:15
On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
[off-list ref] wrote:
CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
this change does not enable 2nd DAWR support.
Signed-off-by: Ravi Bangoria <redacted>
I ran the ptrace-hwbreak selftest successfully within a power10 kvm guest.
Tested-by: Jordan Niethe <redacted>
Since all feat_enable_debug_facilities_v31() does is set
CPU_FTR_DAWR1, if you just have:
{"debug-facilities-v31", feat_enable, CPU_FTR_DAWR1},
I think cpufeatures_process_feature() should set it in for you at this point:
if (m->enable(f)) {
cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
break;
}
From: Jordan Niethe <hidden> Date: 2020-07-20 01:43:07
On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
[off-list ref] wrote:
As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
DAWR is present, otherwise not. Host generally uses "cpu-features",
which masks "pa-features". But "cpu-features" are still not used for
guests and thus this change is mostly applicable for guests only.
Signed-off-by: Ravi Bangoria <redacted>
I checked those PAPR values are correct and checked running a powernv
kernel in p10 mambo with dt_cpu_ftrs=off and it does set the
CPU_FTR_DAWR1 bit.
(using p10 skiboot).
Tested-by: Jordan Niethe <redacted>
From: Jordan Niethe <hidden> Date: 2020-07-20 01:53:27
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.
Signed-off-by: Ravi Bangoria <redacted>
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)staticinlinelongplpar_set_watchpoint0(unsignedlongdawr0,unsignedlongdawrx0){-returnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR,dawr0,dawrx0);+returnplpar_set_mode(0,H_SET_MODE_RESOURCE_SET_DAWR0,dawr0,dawrx0);}staticinlinelongplpar_signal_sys_reset(longcpu)
From: Jordan Niethe <hidden> Date: 2020-07-20 03:46:04
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted hunk
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
So it'd be something like:
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
But thinking that there might be more slots added in the future, it
may be better to make the number of slots a variable that is set
during the init and then have this function return that.
From: Jordan Niethe <hidden> Date: 2020-07-20 06:57:43
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.
It looks like this change is not mentioned in ISA v3.1 Book III 9.4
Data Address Watchpoint. It could be useful to mention that in the
commit message.
Also I wonder if could add a test for this to the ptrace-hwbreak selftest?
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)if(dawr_enabled()){max_len=DAWR_MAX_LEN;-/* DAWR region can't cross 512 bytes boundary */-if(ALIGN_DOWN(start_addr,SZ_512)!=ALIGN_DOWN(end_addr-1,SZ_512))+/* DAWR region can't cross 512 bytes boundary on p10 predecessors */+if(!cpu_has_feature(CPU_FTR_ARCH_31)&&+(ALIGN_DOWN(start_addr,SZ_512)!=ALIGN_DOWN(end_addr-1,SZ_512)))return-EINVAL;}elseif(IS_ENABLED(CONFIG_PPC_8xx)){/* 8xx can setup a range without limitation */--
From: Ravi Bangoria <hidden> Date: 2020-07-21 03:25:32
Hi Jordan,
On 7/20/20 12:24 PM, Jordan Niethe wrote:
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted
Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.
It looks like this change is not mentioned in ISA v3.1 Book III 9.4
Data Address Watchpoint. It could be useful to mention that in the
commit message.
Yes, ISA 3.1 Book III 9.4 has a documentation mistake and hopefully it
will be fixed in the next version of ISA. Though, this is mentioned in
ISA 3.1 change log:
Multiple DEAW:
Added a second Data Address Watchpoint. [H]DAR is
set to the first byte of overlap. 512B boundary is
removed.
I'll mention this in the commit description.
Also I wonder if could add a test for this to the ptrace-hwbreak selftest?
Yes, I already have a selftest for this in perf-hwbreak. Will send that soon.
Thanks,
Ravi
From: Ravi Bangoria <hidden> Date: 2020-07-21 03:58:15
On 7/20/20 9:12 AM, Jordan Niethe wrote:
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
I wonder if these defines are necessary - has it any advantage over
just using the literal?
No, not really. Initially I had something like:
#define HBP_NUM_MAX 2
#define HBP_NUM_P8_P9 1
#define HBP_NUM_P10 2
But then I thought it's also not right. So I made it _ONE and _TWO.
Now the function that decides nr watchpoints dynamically (nr_wp_slots)
is in different file, I thought to keep it like this so it would be
easier to figure out why _MAX is 2.
So it'd be something like:
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
But thinking that there might be more slots added in the future, it
may be better to make the number of slots a variable that is set
during the init and then have this function return that.
Not sure I follow. What do you mean by setting number of slots a
variable that is set during the init?
Thanks,
Ravi
From: Jordan Niethe <hidden> Date: 2020-07-21 04:41:51
On Tue, Jul 21, 2020 at 1:57 PM Ravi Bangoria
[off-list ref] wrote:
On 7/20/20 9:12 AM, Jordan Niethe wrote:
quoted
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
I wonder if these defines are necessary - has it any advantage over
just using the literal?
No, not really. Initially I had something like:
#define HBP_NUM_MAX 2
#define HBP_NUM_P8_P9 1
#define HBP_NUM_P10 2
But then I thought it's also not right. So I made it _ONE and _TWO.
Now the function that decides nr watchpoints dynamically (nr_wp_slots)
is in different file, I thought to keep it like this so it would be
easier to figure out why _MAX is 2.
So it'd be something like:
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
But thinking that there might be more slots added in the future, it
may be better to make the number of slots a variable that is set
during the init and then have this function return that.
Not sure I follow. What do you mean by setting number of slots a
variable that is set during the init?
Sorry I was unclear there.
I was just looking and saw arm also has a variable number of hw breakpoints.
If we did something like how they handle it, it might look something like:
static int num_wp_slots __ro_after_init;
int nr_wp_slots(void) {
return num_wp_slots;
}
static int __init arch_hw_breakpoint_init(void) {
num_wp_slots = work out how many wp_slots
}
arch_initcall(arch_hw_breakpoint_init);
Then we wouldn't have to calculate everytime nr_wp_slots() is called.
In the future if more wp's are added nr_wp_slots() will get more complicated.
But just an idea, feel free to ignore.
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:
{ /* 3.1-compliant processor, i.e. Power10 "architected" mode */
.pvr_mask = 0xffffffff,
.pvr_value = 0x0f000006,
.cpu_name = "POWER10 (architected)",
.cpu_features = CPU_FTRS_POWER10,
Since all feat_enable_debug_facilities_v31() does is set
CPU_FTR_DAWR1, if you just have:
{"debug-facilities-v31", feat_enable, CPU_FTR_DAWR1},
I think cpufeatures_process_feature() should set it in for you at this point:
if (m->enable(f)) {
cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
break;
}
So it'd be something like:
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_MAX : 1;
But thinking that there might be more slots added in the future, it
may be better to make the number of slots a variable that is set
during the init and then have this function return that.
Not sure I follow. What do you mean by setting number of slots a
variable that is set during the init?
Sorry I was unclear there.
I was just looking and saw arm also has a variable number of hw breakpoints.
If we did something like how they handle it, it might look something like:
static int num_wp_slots __ro_after_init;
int nr_wp_slots(void) {
return num_wp_slots;
}
static int __init arch_hw_breakpoint_init(void) {
num_wp_slots = work out how many wp_slots
}
arch_initcall(arch_hw_breakpoint_init);
Then we wouldn't have to calculate everytime nr_wp_slots() is called.
In the future if more wp's are added nr_wp_slots() will get more complicated.
But just an idea, feel free to ignore.
Ok I got the idea. But ARM arch_hw_breakpoint_init() is much more complex
compared to our nr_wp_slots(). I don't see any benefit by making our code
like ARM.
Thanks for the idea though :)
Ravi
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:
{ /* 3.1-compliant processor, i.e. Power10 "architected" mode */
.pvr_mask = 0xffffffff,
.pvr_value = 0x0f000006,
.cpu_name = "POWER10 (architected)",
.cpu_features = CPU_FTRS_POWER10,
The pa-features logic will turn it off if the feature bit is not set.
So you should be able to put it in CPU_FTRS_POWER10.
See for example CPU_FTR_NOEXECUTE.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-07-21 11:36:58
Ravi Bangoria [off-list ref] writes:
On 7/20/20 9:12 AM, Jordan Niethe wrote:
quoted
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
I wonder if these defines are necessary - has it any advantage over
just using the literal?
No, not really. Initially I had something like:
#define HBP_NUM_MAX 2
#define HBP_NUM_P8_P9 1
#define HBP_NUM_P10 2
But then I thought it's also not right. So I made it _ONE and _TWO.
Now the function that decides nr watchpoints dynamically (nr_wp_slots)
is in different file, I thought to keep it like this so it would be
easier to figure out why _MAX is 2.
I don't think it makes anything clearer.
I had to stare at it thinking there was some sort of mapping or
indirection going on, before I realised it's just literally the number
of breakpoints.
So please just do:
static inline int nr_wp_slots(void)
{
return cpu_has_feature(CPU_FTR_DAWR1) ? 2 : 1;
}
If you think HBP_NUM_MAX needs explanation then do that with a comment,
it can refer to nr_wp_slots() if that's helpful.
cheers
From: Ravi Bangoria <hidden> Date: 2020-07-21 13:33:48
On 7/21/20 5:06 PM, Michael Ellerman wrote:
Ravi Bangoria [off-list ref] writes:
quoted
On 7/20/20 9:12 AM, Jordan Niethe wrote:
quoted
On Fri, Jul 17, 2020 at 2:11 PM Ravi Bangoria
[off-list ref] wrote:
quoted
So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria <redacted>
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
I wonder if these defines are necessary - has it any advantage over
just using the literal?
No, not really. Initially I had something like:
#define HBP_NUM_MAX 2
#define HBP_NUM_P8_P9 1
#define HBP_NUM_P10 2
But then I thought it's also not right. So I made it _ONE and _TWO.
Now the function that decides nr watchpoints dynamically (nr_wp_slots)
is in different file, I thought to keep it like this so it would be
easier to figure out why _MAX is 2.
I don't think it makes anything clearer.
I had to stare at it thinking there was some sort of mapping or
indirection going on, before I realised it's just literally the number
of breakpoints.
So please just do:
static inline int nr_wp_slots(void)
{
return cpu_has_feature(CPU_FTR_DAWR1) ? 2 : 1;
}
If you think HBP_NUM_MAX needs explanation then do that with a comment,
it can refer to nr_wp_slots() if that's helpful.
Agreed. By adding a comment, we can remove those macros. Will change it.
Thanks,
Ravi
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:
{ /* 3.1-compliant processor, i.e. Power10 "architected" mode */
.pvr_mask = 0xffffffff,
.pvr_value = 0x0f000006,
.cpu_name = "POWER10 (architected)",
.cpu_features = CPU_FTRS_POWER10,
The pa-features logic will turn it off if the feature bit is not set.
So you should be able to put it in CPU_FTRS_POWER10.
See for example CPU_FTR_NOEXECUTE.
Ah ok. scan_features() clears the feature if the bit is not set in
pa-features. So it should work find for powervm. I'll verify the same
thing happens in case of baremetal where we use cpu-features not
pa-features. If it works in baremetal as well, will put it in
CPU_FTRS_POWER10.
Thanks for the clarification,
Ravi
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:
{ /* 3.1-compliant processor, i.e. Power10 "architected" mode */
.pvr_mask = 0xffffffff,
.pvr_value = 0x0f000006,
.cpu_name = "POWER10 (architected)",
.cpu_features = CPU_FTRS_POWER10,
The pa-features logic will turn it off if the feature bit is not set.
So you should be able to put it in CPU_FTRS_POWER10.
See for example CPU_FTR_NOEXECUTE.
Ah ok. scan_features() clears the feature if the bit is not set in
pa-features. So it should work find for powervm. I'll verify the same
thing happens in case of baremetal where we use cpu-features not
pa-features. If it works in baremetal as well, will put it in
CPU_FTRS_POWER10.
When we use DT CPU features we don't use CPU_FTRS_POWER10 at all.
We construct a cpu_spec from scratch with just the base set of features:
static struct cpu_spec __initdata base_cpu_spec = {
.cpu_name = NULL,
.cpu_features = CPU_FTRS_DT_CPU_BASE,
And then individual features are enabled via the device tree flags.
cheers
Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.
I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:
{ /* 3.1-compliant processor, i.e. Power10 "architected" mode */
.pvr_mask = 0xffffffff,
.pvr_value = 0x0f000006,
.cpu_name = "POWER10 (architected)",
.cpu_features = CPU_FTRS_POWER10,
The pa-features logic will turn it off if the feature bit is not set.
So you should be able to put it in CPU_FTRS_POWER10.
See for example CPU_FTR_NOEXECUTE.
Ah ok. scan_features() clears the feature if the bit is not set in
pa-features. So it should work find for powervm. I'll verify the same
thing happens in case of baremetal where we use cpu-features not
pa-features. If it works in baremetal as well, will put it in
CPU_FTRS_POWER10.
When we use DT CPU features we don't use CPU_FTRS_POWER10 at all.
We construct a cpu_spec from scratch with just the base set of features:
static struct cpu_spec __initdata base_cpu_spec = {
.cpu_name = NULL,
.cpu_features = CPU_FTRS_DT_CPU_BASE,
And then individual features are enabled via the device tree flags.
Ah good. I was under a wrong impression that we use cpu_specs[] for all
the cases. Thanks mpe for explaining in detail :)
Ravi