RISC-V PMU driver issue

[Atish Patra]

On Tue, Feb 27, 2024 at 7:49 PM 雷博涵 <garthlei at pku.edu.cn> wrote:
>
> Hi all,
>
> I am having problems with the RISC-V PMU driver. The overflow handler of my custom perf event kernel counter seems to read an incorrect value from the event.

If I understand you correctly, you have a custom kernel counter for
the perf event ? Can you explain the use case for that ?

> It seems that the issue lies in the function `riscv_pmu_event_set_period`, which sets `prev_count` to a new value but does not modify the underlying hardware counter. When `perf_event_read_value` gets called later in the user-defined overflow handler, `riscv_pmu_event_update` will update the `count` field again based on the unmodified hardware counter value and the modified `prev_count` field, which causes an incorrect reading.

What do you mean by user defined overflow handler ? The overflow
handler registered via the custom perf event kernel counter which gets
invoked from perf_event_overflow ?

> I noticed that other PMU drivers, such as the ARM one, write to the underlying counter in their set_period functions, which prevents the problem. However, the RISC-V SBI specification does not have such an API to write to a counter without starting it. Using `local64_read(&hw_evt->period_left) <= 0` directly as the guard condition to place `riscv_pmu_event_set_period(event)` after it seems to work, but I am not sure whether it can cause other issues.

Not sure the exact code path you are referring to. You don't want to
invoke  riscv_pmu_event_set_period if period_left <= 0 ?

>
> Thank you,
> Bohan Lei


-- 
Regards,
Atish