On Thu, Jul 9, 2020 at 6:21 PM Anup Patel <Anup.Patel@...> wrote:
-----Original Message-----
From: tech-unixplatformspec@... <tech-
unixplatformspec@...> On Behalf Of Zong Li
Sent: 09 July 2020 14:42
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 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.
The above break-up of 0x12345678 RAW event is only one of the possible
ways shown as example.
If we have two different RAW events 0xXXXXX678 and 0xYYYYY678 then
platform can show it as:
event_idx.type == 2 and event_idx.code == X and event_idx.info = 0xXXXXX678
event_idx.type == 2 and event_idx.code == Y and event_idx.info = 0xYYYYY678
OR
event_idx.type == 2 and event_idx.code == Z and event_idx.info = 0xXXXXX678
event_idx.type == 2 and event_idx.code == Z and event_idx.info = 0xYYYYY678
Further, the OpenSBI platform support can translate RAW event_idx into
final mhpmeventX CSR value using platform callback or describing it in DT/ACPI
for OpenSBI generic platform.
I understand that mapping of event_idx to HPMEVENT CSR value is
platform-dependent, and m-mode firmware of each platform knows how to
translate it. But there are still some problems which are ambiguous about
Event_list and event_idx. Could you please help to clarify the question as
follows:
Does the RAW events need to be mapped (i.e. "event_idx.type == 0x2,
event_idx.code == 0x1" is corresponding to some HPMEVENT value)
OR just use raw data for event_idx (i.e. event_idx.info and event_code
hold the raw data directly)? There are different issues for that respectively,
please see the cases as follows:
1) RAW events should be mapped like HW events and HW cache events:
- We assume event_idx.code == 0x1 is corresponding to HPMEVENT
value 0x1234, and event_idx.code == 0x2 is corresponding to HPMEVENT
value 0x5678, so in s-mode software, I expect that I would get the event
support list "Event_list" which has the elements 0x2001 and 0x2002.
When the user mode perf tool creates a RAW event 0x1234, Linux PMU
driver tries to find an appropriate counter by checking the event support
list "Event_list', but Linux PMU driver doesn't know the relationship
between 0x1234 and 0x2001, so it couldn't decide if this counter is good
for it.
2) Use RAW data of RAW event:
- The size of HPMEVENT CSR is MXLEN, so it could be 64-bits. The size of
event_idx.info + event_idx.code is only 59 bits, it doesn't seem
to be enough.
In addition, the event support list "Event_list" is consist of
event_idx.type
and event_idx.code, it doesn't include event_idx.info, so it would
be conflicting
in Event_list if there are events which have the same low 12-bits.
For example,
0xXXXXX678 is 0x2678 in Event_list, and 0xYYYYY678 is also 0x2678 in
Event_list. When the user mode perf tool creates a RAW event 0xXXXXX678,
Linux PMU driver tries to find an appropriate counter by checking the event
support list "Event_list", it couldn't decide if this counter is
good, because
it doesn't know the 0x2678 in Event_list means 0xXXXXX678 or 0xYYYYY678.
If I understand correctly above. we should come out a new format for Event_list
and event_idx or provide a new SBI call to fix that.
In other words, we have to distinguish all HARDWARE and SOFTWARE
events of a platform using 16bit event_idx.type and event_idx.code. The
event_idx.info is only additional parameter to a event.
Regards,
Anup
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
