Re: Questions on HPMs
Beeman Strong
You just beat me, I had a mail to the same effect in progress. For instructions I agree that events, like instret, should be based on the originating PL. Other uarch events, like cycles or stalls, will naturally depend on implementation but ideally would be associated with the originating PL as much as possible.
For interrupts or exceptions, I think it's the opposite: events will ideally depend on the destination PL. Since these operations don't increment instret I'm not sure there's a hard and fast rule here, so perhaps it's just up to implementations how they handle these cases. But suffice it to say that events that count interrupts or page faults, for instance, would not be expected by a user profiler.
From an implementation perspective, the best approach would seem to be to increment most non-uarch events (like instret) at retire, using the PL at retire. xRET will require special treatment, to increment events before the PL change.
On Fri, Oct 29, 2021 at 8:22 AM Ved Shanbhogue <ved@...> wrote:
On Thu, Oct 28, 2021 at 04:36:19PM -0700, Andrew Waterman wrote:
> On Thu, Oct 28, 2021 at 4:18 PM Greg Favor <gfavor@...> wrote:
>
> > On Thu, Oct 28, 2021 at 3:21 PM Beeman Strong <beeman@...> wrote:
> >
> >> 2) I haven't seen a clear definition of what instret counts, other than:
> >>
> >> * The minstret CSR counts the number of instructions the hart has retired.
> >> * As ECALL and EBREAK cause synchronous exceptions, they are not
> >> considered to retire, and should not increment the minstret CSR.
> >>
> >> From this I'm inferring that neither interrupts nor instructions that
> >> take exceptions increment instret. Is that right?
> >>
> >
> > Andrew can confirm, but I believe the answer is Yes. Which makes sense
> > since in both cases an instruction is not successfully executed (and one
> > doesn't want double-counting of an instruction that first takes an
> > exception and then successfully executes after return from the exception,
> > e.g. a page fault).
> >
>
> 👍
>
A related question. With privilege mode based inhibits the treatment of instructions
that cross privilege mode is not explicitly defined in the Sscofmpf extension. For
example, ECALL and EBREAK will not count as instruction retired but they may count
other events. To take a hypothetical example, if there was a event for a uncompressed
instruction starting at unliagned address. Likewise SRET and MRET are eligible to be
counted as instructions and may also trigger other events.
In all these cases where the instruction leads to a privilege domain change it would be good
clarify that the inhibits at the originating privilege domain that apply for the counting.
I hope thats the agreed upon expected behavior?
regards
ved