t-pmu.c
>
> EVENT(PM_CYC_ALT, 0x100f0)
> EVENT(PM_CYC, 0x600f4)
>
> In this case, we can have only two cycles events to go in a group. So with
> our testcase events, one leader and only one sibling event
> can go in a group (checked other PMU’s to confirm two is possible). So added
> this fix to consider instructions as one of the sibling event.
Thanks for the explanation.
Reviewed-by: Ravi Bangoria
Thanks,
Ravi
Hi Athira,
On 10-Jan-25 3:16 PM, Athira Rajeev wrote:
> In some of the powerpc platforms, event group testcase fails as below:
>
># perf test -v 'Event groups'
>69: Event groups:
>--- start ---
>test child forked, pid 9765
>U
ed by Qemu remote debug handler. Bus Lock Detect is one such case.
[1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
2023, Vol 2, 13.1.3.6 Bus Lock Trap
https://bugzilla.kernel.org/attachment.cgi?id=304653
Signed-off-by: Ravi Bangoria
---
Kernel and KVM patches:
permissions to access hv_24x7 pmu counters. If not, event_open
> will fail. Hence add a sanity check to see if event_open
> succeeds before proceeding with the test.
>
> Fixes: b20d9215a35f ("perf test: Add event group test for events in multiple
> PMUs")
> Signed-off-
On 14-Oct-22 3:26 PM, Ravi Bangoria wrote:
> On 13-Oct-22 4:29 PM, Peter Zijlstra wrote:
>> On Thu, Oct 13, 2022 at 03:37:23PM +0530, Ravi Bangoria wrote:
>>
>>>> - refcount_t refcount;
>>>> + refcount_t refcount;
On 13-Oct-22 4:29 PM, Peter Zijlstra wrote:
> On Thu, Oct 13, 2022 at 03:37:23PM +0530, Ravi Bangoria wrote:
>
>>> - refcount_t refcount;
>>> + refcount_t refcount; /* event <-> ctx */
>>
>> Ok. We need to
On 13-Oct-22 2:17 AM, Peter Zijlstra wrote:
> On Wed, Oct 12, 2022 at 02:16:29PM +0200, Peter Zijlstra wrote:
>
>> That's the intent yeah. But due to not always holding ctx->mutex over
>> put_pmu_ctx() this might be moot. I'm almost through auditing epc usage
>> and I think ctx->lock is sufficient
On 11-Oct-22 11:17 PM, Peter Zijlstra wrote:
> On Tue, Oct 11, 2022 at 04:02:56PM +0200, Peter Zijlstra wrote:
>> On Tue, Oct 11, 2022 at 06:49:55PM +0530, Ravi Bangoria wrote:
>>> On 11-Oct-22 4:59 PM, Peter Zijlstra wrote:
>>>> On Sat, Oct 08, 2022 at 11:54:2
On 11-Oct-22 4:59 PM, Peter Zijlstra wrote:
> On Sat, Oct 08, 2022 at 11:54:24AM +0530, Ravi Bangoria wrote:
>
>> +static void perf_event_swap_task_ctx_data(struct perf_event_context
>> *prev_ctx,
>> + struct perf_event_context *next_c
On 10-Oct-22 3:53 PM, Peter Zijlstra wrote:
> On Tue, Sep 06, 2022 at 11:20:53AM +0530, Ravi Bangoria wrote:
>
>> This one was simple enough so I prepared a patch for this. Let
>> me know if you see any issues with below diff.
>
> I've extraed this as a separate
On 10-Oct-22 3:44 PM, Peter Zijlstra wrote:
> On Wed, Sep 07, 2022 at 04:58:49PM +0530, Ravi Bangoria wrote:
>>> -static void
>>> -ctx_flexible_sched_in(struct perf_event_context *ctx,
>>> - struct perf_cpu_context *cpuctx)
>>> +/* XXX .busy t
> -static void
> -ctx_flexible_sched_in(struct perf_event_context *ctx,
> - struct perf_cpu_context *cpuctx)
> +/* XXX .busy thingy from Peter's patch */
> +static void ctx_flexible_sched_in(struct perf_event_context *ctx, struct pmu
> *pmu)
This one turned out to be very easy.
> @@ -9752,10 +9889,13 @@ void perf_tp_event(u16 event_type, u64 count, void
> *record, int entry_size,
> struct trace_entry *entry = record;
>
> rcu_read_lock();
> - ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]);
> + ctx = rcu_
> So the basic issue I mentioned is that:
>
>
> /*
> * ,[1:n]-.
> * V V
> * perf_event_context <-[1:n]-> perf_event_pmu_context <--- perf_event
> * ^
On 29-Aug-22 8:10 PM, Peter Zijlstra wrote:
> On Mon, Aug 29, 2022 at 02:04:33PM +0200, Peter Zijlstra wrote:
>> On Mon, Aug 29, 2022 at 05:03:47PM +0530, Ravi Bangoria wrote:
>>> @@ -12598,6 +12590,7 @@ EXPORT_SYMBOL_GPL(perf_event_create_kernel_counter);
>>>
>>
o rbtree and
minheap layouts.
[1]: https://lore.kernel.org/r/8d91528b-e830-6ad0-8a92-621ce9f944ca%40amd.com
Signed-off-by: Peter Zijlstra
Signed-off-by: Ravi Bangoria
---
This is a 3rd version of perf event context rework and it's quite
stable now, so I thought to remove RFC tag. Pre
@@ -763,6 +771,14 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
/* dst = *(u16 *)(ul) (src + off) */
case BPF_LDX | BPF_MEM | BPF_H:
case BPF_LDX | BPF_PROBE_MEM | BPF_H:
+ if (BPF_MODE(code) == BPF_PROBE_MEM) {
+
On 7/6/21 3:23 PM, Christophe Leroy wrote:
Le 06/07/2021 à 09:32, Ravi Bangoria a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Can you do the same for 32bit ?
Sure. But before that
> TASK_SIZE_MAX, otherwise set dst_reg=0 and move on.
This will catch NULL, valid or invalid userspace pointers. Only bad
kernel pointer will be handled by BPF exception table.
[Alexei suggested for x86]
Suggested-by: Alexei Starovoitov
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit_com
r r3,r3,r3 |
| b 0x40b0 |
|--|
0x4290 -->| insn=0xfd90 | \ extable entry
| fixup=0xffec | /
0x4298 -->| insn=0xfe14 |
| fixup=0xffec |
+--+
(Addresses shown here are chosen random, no
In case of extra_pass, we always skips usual JIT passes. Thus
extra_pass is always false while calling bpf_jit_build_body()
and thus it can be removed.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h| 2 +-
arch/powerpc/net/bpf_jit_comp.c | 6 +++---
arch/powerpc/net
Patch #1, #2 are simple cleanup patches. Patch #3 adds
BPF_PROBE_MEM support with PowerPC 64bit JIT compiler.
Patch #4 adds explicit addr > TASK_SIZE_MAX check to
handle bad userspace pointers.
Ravi Bangoria (4):
bpf powerpc: Remove unused SEEN_STACK
bpf powerpc: Remove extra_pass f
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 99fad093f43e
Hi Cedric,
On 4/21/21 12:01 PM, Cédric Le Goater wrote:
On 4/21/21 8:20 AM, Ravi Bangoria wrote:
Hi David,
On 4/19/21 10:23 AM, David Gibson wrote:
On Mon, Apr 12, 2021 at 05:14:33PM +0530, Ravi Bangoria wrote:
As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability
Hi David,
On 4/19/21 10:23 AM, David Gibson wrote:
On Mon, Apr 12, 2021 at 05:14:33PM +0530, Ravi Bangoria 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. Use
Update against Linux 5.12-rc3
Signed-off-by: Ravi Bangoria
---
include/standard-headers/drm/drm_fourcc.h | 23 -
include/standard-headers/linux/input.h| 2 +-
.../standard-headers/rdma/vmw_pvrdma-abi.h| 7 ++
linux-headers/asm-generic/unistd.h| 4 +-
linux
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by Qemu.
One exception to this is KVM_REG_PPC_DAWR[X]. This is from kernel
uapi header and thus not changed in kernel as well as Qemu.
Signed-off-by: Ravi Bangoria
Reviewed
separate patch. (Sync
headers from v5.12-rc3)
[1] https://git.kernel.org/torvalds/c/bd1de1a0e6eff
Ravi Bangoria (3):
Linux headers: update from 5.12-rc3
ppc: Rename current DAWR macros and variables
ppc: Enable 2nd DAWR support on p10
hw/ppc/spapr.c| 7 +
ature bit in guest DT using cap-dawr1 machine
capability. Though, watchpoint on powerpc TCG guest is not supported
and thus 2nd DAWR is not enabled for TCG mode.
Signed-off-by: Ravi Bangoria
Reviewed-by: Greg Kurz
---
hw/ppc/spapr.c | 7 ++-
hw/ppc/spapr_caps.c
nt (Non-overlapping): Ok
ptrace thread event -> perf other thread & cpu event: Ok
success: ptrace-perf-hwbreak
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/.gitignore | 1 +
.../testing/selftests/powerpc/ptrace/Makefile | 2 +-
.../powerpc/ptrace/ptrace-per
, one is RO, other is WO
TESTED: Process specific, 512 bytes, unaligned
success: perf_hwbreak
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 552 +-
1 file changed, 551 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc
perf-hwbreak selftest opens hw-breakpoint event at multiple places for
which it has same code repeated. Coalesce that code into a function.
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 79 +--
1 file changed, 39 insertions(+), 40 deletions
, len: 6: Ok
PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, RO, len: 6: Ok
Signed-off-by: Ravi Bangoria
Reviewed-by: Daniel Axtens
---
.../selftests/powerpc/ptrace/ptrace-hwbreak.c | 79 +++
1 file changed, 79 insertions(+)
diff --git a/tools/testing/selftests/powerpc/ptrace
2058.312282-1-ravi.bango...@linux.ibm.com
v1->v2:
- Kvm patches are already upstream
- Rebased selftests to powerpc/next
Ravi Bangoria (4):
powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd DAWR
powerpc/selftests/perf-hwbreak: Coalesce event creation code
powerpc/selftests/perf-hwbreak: A
On 4/9/21 12:49 PM, Daniel Axtens wrote:
Hi Ravi,
perf-hwbreak selftest opens hw-breakpoint event at multiple places for
which it has same code repeated. Coalesce that code into a function.
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 78
On 4/9/21 12:22 PM, Daniel Axtens wrote:
Hi Ravi,
Add selftests to test multiple active DAWRs with ptrace interface.
It would be good if somewhere (maybe in the cover letter) you explain
what DAWR stands for and where to find more information about it. I
found the Power ISA v3.1 Book 3 Chap
+static void cap_dawr1_apply(SpaprMachineState *spapr, uint8_t val,
+ Error **errp)
+{
+ERRP_GUARD();
+if (!val) {
+return; /* Disable by default */
+}
+
+if (tcg_enabled()) {
+error_setg(errp, "DAWR1 not supported in TCG.");
+
nt (Non-overlapping): Ok
ptrace thread event -> perf other thread & cpu event: Ok
success: ptrace-perf-hwbreak
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/.gitignore | 1 +
.../testing/selftests/powerpc/ptrace/Makefile | 2 +-
.../powerpc/ptrace/ptrace-per
, one is RO, other is WO
TESTED: Process specific, 512 bytes, unaligned
success: perf_hwbreak
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 568 +-
1 file changed, 567 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc
perf-hwbreak selftest opens hw-breakpoint event at multiple places for
which it has same code repeated. Coalesce that code into a function.
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 78 +--
1 file changed, 38 insertions(+), 40 deletions
, len: 6: Ok
PPC_PTRACE_SETHWDEBUG 2, MODE_RANGE, DAWR Overlap, RO, len: 6: Ok
Signed-off-by: Ravi Bangoria
---
.../selftests/powerpc/ptrace/ptrace-hwbreak.c | 79 +++
1 file changed, 79 insertions(+)
diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
b/tools
Add selftests for 2nd DAWR supported by Power10.
v1:
https://lore.kernel.org/r/20200723102058.312282-1-ravi.bango...@linux.ibm.com
v1->v2:
- Kvm patches are already upstream
- Rebased selftests to powerpc/next
Ravi Bangoria (4):
powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd D
ature bit in guest DT using cap-dawr1 machine
capability. Though, watchpoint on powerpc TCG guest is not supported
and thus 2nd DAWR is not enabled for TCG mode.
Signed-off-by: Ravi Bangoria
---
hw/ppc/spapr.c | 7 ++-
hw/ppc/spapr_caps.c
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by Qemu.
One exception to this is KVM_REG_PPC_DAWR[X]. This is from kernel
uapi header and thus not changed in kernel as well as Qemu.
Signed-off-by: Ravi Bangoria
Reviewed
Update against Linux 5.12-rc3
Signed-off-by: Ravi Bangoria
---
include/standard-headers/drm/drm_fourcc.h | 23 -
include/standard-headers/linux/input.h| 2 +-
.../standard-headers/rdma/vmw_pvrdma-abi.h| 7 ++
linux-headers/asm-generic/unistd.h| 4 +-
linux
uests even
when host kvm supports it. User has to manually enable it
with -machine cap-dawr1=on if he wishes to use it.
- Split the header file changes into separate patch. (Sync
headers from v5.12-rc3)
[1] https://git.kernel.org/torvalds/c/bd1de1a0e6eff
Ravi Bangoria (3):
Linux h
On 3/31/21 5:06 AM, David Gibson wrote:
On Tue, Mar 30, 2021 at 06:48:38PM +0200, Greg Kurz wrote:
On Tue, 30 Mar 2021 15:23:50 +0530
Ravi Bangoria 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
Update against Linux 5.12-rc3
Signed-off-by: Ravi Bangoria
---
include/standard-headers/drm/drm_fourcc.h | 23 -
include/standard-headers/linux/input.h| 2 +-
.../standard-headers/rdma/vmw_pvrdma-abi.h| 7 ++
linux-headers/asm-generic/unistd.h| 4 +-
linux
ature bit in guest DT using cap-dawr1 machine
capability. Though, watchpoint on powerpc TCG guest is not supported
and thus 2nd DAWR is not enabled for TCG mode.
Signed-off-by: Ravi Bangoria
---
hw/ppc/spapr.c | 11 ++-
hw/ppc/spapr_caps.c
headers from v5.12-rc3)
[1] https://git.kernel.org/torvalds/c/bd1de1a0e6eff
Ravi Bangoria (3):
Linux headers: update from 5.12-rc3
ppc: Rename current DAWR macros and variables
ppc: Enable 2nd DAWR support on p10
hw/ppc/spapr.c| 11 ++-
hw/
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by Qemu.
One exception to this is KVM_REG_PPC_DAWR[X]. This is from kernel
uapi header and thus not changed in kernel as well as Qemu.
Signed-off-by: Ravi Bangoria
Hi David,
@@ -241,6 +241,31 @@ static void spapr_dt_pa_features(SpaprMachineState *spapr,
/* 60: NM atomic, 62: RNG */
0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 60 - 65 */
};
+uint8_t pa_features_310[] = { 66, 0,
+/* 0: MMU|FPU|SLB|RUN|DABR|NX, 1: fri[nzpm]|DAB
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by Qemu.
One exception to this is KVM_REG_PPC_DAWR[X]. This is from kernel
uapi header and thus not changed in kernel as well as Qemu.
Signed-off-by: Ravi Bangoria
Update against Linux 5.12-rc3
Signed-off-by: Ravi Bangoria
---
include/standard-headers/drm/drm_fourcc.h | 23 ++-
include/standard-headers/linux/input.h | 2 +-
include/standard-headers/rdma/vmw_pvrdma-abi.h | 7 ++
linux-headers/asm-generic/unistd.h | 4
ature bit in guest DT using cap-dawr1 machine
capability.
Signed-off-by: Ravi Bangoria
---
hw/ppc/spapr.c | 34 ++
hw/ppc/spapr_caps.c | 32
include/hw/ppc/spapr.h | 6 +-
target/ppc/
ges into separate patch. (Sync
headers from v5.12-rc3)
[1] https://git.kernel.org/torvalds/c/bd1de1a0e6eff
Ravi Bangoria (3):
Linux headers: update from 5.12-rc3
ppc: Rename current DAWR macros and variables
ppc: Enable 2nd DAWR support on p10
hw/ppc/spap
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
Acked-by: Naveen N. Rao
Acked-by: Sandipan Das
---
v4:
https://lore.kernel.org/r/20210305115433.140769-1-ravi.bango...@linux.ibm.com
v4->v5:
- Replace SZ_ macros with numbers
arch/powerpc/kernel/uprob
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
Acked-by: Naveen N. Rao
Acked-by: Sandipan Das
---
v4:
https://lore.kernel.org/r/20210305115433.140769-1-ravi.bango...@linux.ibm.com
v4->v5:
- Replace SZ_ macros with numbers
arch/powerpc/kernel/uprob
On 3/9/21 4:51 PM, Naveen N. Rao wrote:
On 2021/03/09 08:54PM, Michael Ellerman wrote:
Ravi Bangoria writes:
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.
There are two ways probed instruction is chang
On 3/9/21 4:51 PM, Naveen N. Rao wrote:
On 2021/03/09 08:54PM, Michael Ellerman wrote:
Ravi Bangoria writes:
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.
There are two ways probed instruction is chang
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
Acked-by: Naveen N. Rao
---
v3: https://lore.kernel.org/r/20210304050529.59391-1-ravi.bango...@linux.ibm.com
v3->v4:
- CONFIG_PPC64 check was not required, remove it.
- Use SZ_ macros instead of hardcoded numbers
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
Acked-by: Naveen N. Rao
---
v3: https://lore.kernel.org/r/20210304050529.59391-1-ravi.bango...@linux.ibm.com
v3->v4:
- CONFIG_PPC64 check was not required, remove it.
- Use SZ_ macros instead of hardcoded numbers
On 3/4/21 4:21 PM, Christophe Leroy wrote:
Le 04/03/2021 à 11:13, Ravi Bangoria a écrit :
On 3/4/21 1:02 PM, Christophe Leroy wrote:
Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on
On 3/4/21 4:21 PM, Christophe Leroy wrote:
Le 04/03/2021 à 11:13, Ravi Bangoria a écrit :
On 3/4/21 1:02 PM, Christophe Leroy wrote:
Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on
On 3/4/21 1:02 PM, Christophe Leroy wrote:
Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.
There are two ways probed instruction is changed in mapped pages.
On 3/4/21 1:02 PM, Christophe Leroy wrote:
Le 04/03/2021 à 06:05, Ravi Bangoria a écrit :
As per ISA 3.1, prefixed instruction should not cross 64-byte
boundary. So don't allow Uprobe on such prefixed instruction.
There are two ways probed instruction is changed in mapped pages.
@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
+ if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))
+ return 0;
Sorry, I missed this last time, but I think we can drop the
@@ -41,6 +41,14 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
+ if (!IS_ENABLED(CONFIG_PPC64) || !cpu_has_feature(CPU_FTR_ARCH_31))
+ return 0;
Sorry, I missed this last time, but I think we can drop the
stdio
# Samples: 8K of event 'cycles'
# Event count (approx.): 8784
...
Reported-by: Athira Rajeev
Fixes: aa6b3c99236b ("perf report: Make -F more strict like -s")
Signed-off-by: Ravi Bangoria
---
tools/perf/util/sort.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
---
v2:
https://lore.kernel.org/r/20210204104703.273429-1-ravi.bango...@linux.ibm.com
v2->v3:
- Drop restriction for Uprobe on suffix of prefixed instruction.
It needs lot of code change including generic code
d. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
---
v2:
https://lore.kernel.org/r/20210204104703.273429-1-ravi.bango...@linux.ibm.com
v2->v3:
- Drop restriction for Uprobe on suffix of prefixed instruction.
It needs lot of code change including generic code
99da74333b ("powerpc/sstep: Support VSX vector paired storage access
instructions")
Signed-off-by: Jordan Niethe
Yikes!
Reviewed-by: Ravi Bangoria
On 2/4/21 6:38 PM, Naveen N. Rao wrote:
On 2021/02/04 04:17PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
The
On 2/4/21 9:42 PM, Naveen N. Rao wrote:
On 2021/02/04 06:38PM, Naveen N. Rao wrote:
On 2021/02/04 04:17PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Upro
On 2/4/21 6:38 PM, Naveen N. Rao wrote:
On 2021/02/04 04:17PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
The
On 2/4/21 6:45 PM, Naveen N. Rao wrote:
On 2021/02/04 04:19PM, Ravi Bangoria wrote:
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Upro
On 2/4/21 9:42 PM, Naveen N. Rao wrote:
On 2021/02/04 06:38PM, Naveen N. Rao wrote:
On 2021/02/04 04:17PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Upro
On 2/6/21 11:36 PM, Oleg Nesterov wrote:
On 02/04, Ravi Bangoria wrote:
+static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
+{
+ struct page *page;
+ struct vm_area_struct *vma;
+ void *kaddr;
+ unsigned int gup_flags = FOLL_FORCE
On 2/4/21 6:45 PM, Naveen N. Rao wrote:
On 2021/02/04 04:19PM, Ravi Bangoria wrote:
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Upro
On 2/6/21 11:36 PM, Oleg Nesterov wrote:
On 02/04, Ravi Bangoria wrote:
+static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
+{
+ struct page *page;
+ struct vm_area_struct *vma;
+ void *kaddr;
+ unsigned int gup_flags = FOLL_FORCE
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
There are two ways probed instruction is changed
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
There are two ways probed instruction is changed
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
---
v1: http://lore.kernel.org/r/20210119091234.76317-1-ravi.bango...@linux.ibm.com
v1->v2:
- Instead of introducing new arch hook from
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria
---
v1: http://lore.kernel.org/r/20210119091234.76317-1-ravi.bango...@linux.ibm.com
v1->v2:
- Instead of introducing new arch hook from
On 1/28/21 10:50 PM, Naveen N. Rao wrote:
On 2021/01/15 11:46AM, Ravi Bangoria wrote:
Compiling kernel with -Warray-bounds throws below warning:
In function 'emulate_vsx_store':
warning: array subscript is above array bounds [-Warray-bounds]
buf.d[2] = byterev_
storage access
instructions")
Suggested-by: Naveen N. Rao
Signed-off-by: Ravi Bangoria
---
v1: http://lore.kernel.org/r/20210115061620.692500-1-ravi.bango...@linux.ibm.com
v1->v2:
- Change code only in the affected block
arch/powerpc/lib/sstep.c | 14 --
1 file changed, 8 i
On 1/19/21 10:56 PM, Oleg Nesterov wrote:
On 01/19, Ravi Bangoria wrote:
Probe on 2nd word of a prefixed instruction is invalid scenario and
should be restricted.
I don't understand this ppc-specific problem, but...
So far (upto Power9), instruction size was fixed - 4 bytes. But Po
On 1/19/21 10:56 PM, Oleg Nesterov wrote:
On 01/19, Ravi Bangoria wrote:
Probe on 2nd word of a prefixed instruction is invalid scenario and
should be restricted.
I don't understand this ppc-specific problem, but...
So far (upto Power9), instruction size was fixed - 4 bytes. But Po
and continue.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/uprobes.c | 28
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 8
3 files changed, 37 insertions(+)
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel
and continue.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/uprobes.c | 28
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 8
3 files changed, 37 insertions(+)
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel
variable 'union vsx_reg buf' into an array.
Also consider function argument 'union vsx_reg *reg' as array instead
of pointer because callers are actually passing an array to it.
Fixes: af99da74333b ("powerpc/sstep: Support VSX vector paired storage access
instructions&
t the
new member to be added only at the end. i.e. we can allow
nested guest even when L0 hv_guest_state.version > L1
hv_guest_state.version. Though, the other way around is not
possible.
Signed-off-by: Ravi Bangoria
Reviewed-by: Fabiano Rosas
---
arch/powerpc/include/asm/hvcall.
t the
new member to be added only at the end. i.e. we can allow
nested guest even when L0 hv_guest_state.version > L1
hv_guest_state.version. Though, the other way around is not
possible.
Signed-off-by: Ravi Bangoria
Reviewed-by: Fabiano Rosas
---
arch/powerpc/include/asm/hvcall.
Introduce KVM_CAP_PPC_DAWR1 which can be used by Qemu to query whether
kvm supports 2nd DAWR or not. The capability is by default disabled
even when the underlying CPU supports 2nd DAWR. Qemu needs to check
and enable it manually to use the feature.
Signed-off-by: Ravi Bangoria
ch #2: Don't rename KVM_REG_PPC_DAWR, it's an uapi macro
- patch #3: Increment HV_GUEST_STATE_VERSION
- Split kvm and selftests patches into different series
- Patches rebased to paulus/kvm-ppc-next (cf59eb13e151) + few
other watchpoint patches which are yet to be merged in
paulus/kvm-ppc-ne
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by kvm.
One exception is KVM_REG_PPC_DAWR. Keep it as it is because it's
uapi so changing it will break userspace.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/includ
Introduce KVM_CAP_PPC_DAWR1 which can be used by Qemu to query whether
kvm supports 2nd DAWR or not. The capability is by default disabled
even when the underlying CPU supports 2nd DAWR. Qemu needs to check
and enable it manually to use the feature.
Signed-off-by: Ravi Bangoria
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by kvm.
One exception is KVM_REG_PPC_DAWR. Keep it as it is because it's
uapi so changing it will break userspace.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/includ
kvm code assumes single DAWR everywhere. Add code to support 2nd DAWR.
DAWR is a hypervisor resource and thus H_SET_MODE hcall is used to set/
unset it. Introduce new case H_SET_MODE_RESOURCE_SET_DAWR1 for 2nd DAWR.
Also, kvm will support 2nd DAWR only if CPU_FTR_DAWR1 is set.
Signed-off-by: Ravi
ch #2: Don't rename KVM_REG_PPC_DAWR, it's an uapi macro
- patch #3: Increment HV_GUEST_STATE_VERSION
- Split kvm and selftests patches into different series
- Patches rebased to paulus/kvm-ppc-next (cf59eb13e151) + few
other watchpoint patches which are yet to be merged in
paulus/kvm-ppc-ne
1 - 100 of 1491 matches
Mail list logo
