Hi Greg, I think there is some confusion here. The “counter_info” does not related to the mhpmevent CSR value. Rather, the “counter_info” only provides more details about a counter

Hi Tommy, Your suggestion looks good to me as well. I will update to use counter_info[XLEN-1] as “counter type”. Regards, Anup

Hi Brian, Sure, I will include an explicit statement about “SBI PMU extension providing a perf compatible event …” (like you suggested). Regards, Anup

Ok, that sounds completely reasonable. --Sean

Additional discussion at [1]. My objections are particularly motivated by the RFC implementation of this spec for opensbi which just does hang: wfi j hang if it doesn't have a more specific

I want to ask or encourage that this not be done. Here's why: It will be desirable for new CPU implementations to adopt a mhpmevent CSR format that matches what is naturally coming through OpenSBI -

Yes. --Sean

That wouldn’t help 64-bit targets much. Did you mean bit XLEN-1? Tommy

# Profiles and Platform Spec Technical Subcommittee (P2TS) Agenda: 2 Nov # 2020 ## Meeting Info: weekly on Mondays (09:00 PST, 16:00 UTC) Details:

Anup, For HARDWARE events, event_idx.code encodes a standard set of events starting from encoding '0'. Insofar as it would be very nice for this to be writeable as is into an mhpmevent CSR without

It's so great to see more and more Rust implementations! Awesome! I like how you have split the crates out. Any plan on submitting them to crates.io? With more and more embedded Rust work ongoing it

Hello all, This is a proposal to request SBI Implementation ID 5 for the open-source Diosix project: https://github.com/diodesign/diosix Diosix is a bare-metal hypervisor written in Rust for 32- and

OK, these are good answers, but to reword it: We expect all Linux, hypervisors, and distros can be compiled to work with all optional features of a required extension (including privileged and

Right, but the SBI spec is considering the S-mode execution environment. Whether it's still a hart to M-mode is irrelevant (and if the hart was powered down or physically removed it might not be a

Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish

I think this belongs in the SBI specification. There are multiple issues about information expected to be in this ([1], [2]). In addition, some concepts such as the HSM, or the placement of the hartid

Does it need to be specified in SBI specification or platform specification ? Platform specification anyways should have a section about state of machine while entering M/S mode. Keeping the same

I am fine with either way. -- Regards, Atish

There is a brief valid hart definition in binary encoding section as well. "any of the hartid from hart_mask is not valid i.e. either the hartid is not enabled by the platform or is not available to