On Thu, Jul 9, 2020 at 4:47 PM Anup Patel <Anup.Patel@...> wrote:

-----Original Message-----
From: Zong Li <zong.li@...>
Sent: 09 July 2020 14:09
To: Anup Patel <Anup.Patel@...>
Cc: Brian Grayson <brian.grayson@...>; Atish Patra
<Atish.Patra@...>; andrew@...; tech-
unixplatformspec@...; gfavor@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal v2: SBI PMU
Extension

On Thu, Jul 9, 2020 at 3:57 PM Anup Patel <Anup.Patel@...> wrote:

Based on my previous reply…



To monitor RAW event 0x12345678, user-space perf tool will create user

space perf RAW event (i.e. perf_event_attr.type == 4 and
perf_event_attr.config = = 0x12345678). The Linux RISC-V PMU driver will
allocate and map matching HARDWARE counter which supports specified
corrosponding SBI RAW event (event_idx.type = 2, event_idx.code = 0x678
and event_idx.info = 0x12345). Finally, the SBI_PMU_COUNTER_START call
implemented by OpenSBI will write 0x12345678 (or some platform specific
translated value of 0x12345678) to appropriate mhpmeventX CSR).

(Note: above we assume mhpmcounterX supports monitoring RAW event
0x12345678 and OpenSBI is aware of this)

The Linux PMU driver should be aware of this as well, because
SBI_PMU_COUNTER_START takes a parameter for countex_idx which is fed
by Linux PMU driver.

The SBI_PMU_COUNTER_DESCRIBE call is designed considering aspect. This
call provides list of event_idx supported by a given counter_idx (including
RAW events) so when allocating a counter in event_add() we can easily
find matching counter.

Each element of Event_list consists of event_idx.type and
event_idx.code, how does
it present the raw event like above? (event_idx.info = 0x12345,
event_idx.type = 0x2, event_idx.code = 0x678)
It seems to conflict if we have the raw event 0xXXXXX678 and 0xYYYYY678.

This means Linux RISC-V PMU only needs to deal with SBI calls for handling
all types of SBI PMU counters and events. In other words, no need to parse
DT/ACPI for event mappings.

Regards,
Anup

Regards,

Anup





From: Brian Grayson <brian.grayson@...>
Sent: 09 July 2020 12:35
To: Zong Li <zong.li@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra
<Atish.Patra@...>; andrew@...;
tech-unixplatformspec@...; gfavor@...
Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal v2: SBI PMU
Extension



My question is, let's say I know that putting the value 0x12345678 into the

mhpmevent3 register gets me the event I want, and there is no support for
that event in the SBI spec/API. Will this API allow me to program such an
event, basically bypassing the usual mapping functionality? perf basically
allows you to say "I know this event number is not one you know about, but
it's the value I want placed directly into the hardware." I want to ensure that
the full capabilities of the hardware will still be accessible through the SBI
spec in some sort of "raw" mode, and I didn't see a way for that to happen
right now. We don't want to restrict users to the lowest common
denominator of functionality.

Brian





On Wed, Jul 8, 2020 at 10:27 PM Zong Li <zong.li@...> wrote:

On Thu, Jul 9, 2020 at 1:06 AM Brian Grayson <brian.grayson@...>

wrote:

Would there be a raw style interface to access all the SBI-unaware

events, like perf's rNNN support?

Follow this question, in our current proposal, s-mode software only
knows the event_idx, and m-mode firmware takes care of the mapping,

my

question is that s-mode software doesn't seem to understand the
meaning of each event_idx, that means, it just get the array of all
supported event_idx, but couldn't know which one is for what. This
also happened on u-mode program, for rNNN interface, normally, we
should refer to the processor specific documentation for getting these
details, and now, users won't know what value they should give. Please
correct me if I miss something. Thanks.

How would this work on a multicore system -- would the SBI calls only

handle the current hart's counters? That seems easiest to deal with.

Brian