Hi Greg, No response yet, so I’ll give my two cents. I agree the spec is clear on some stuff that is required, and more vague on other stuff. It would be good if the CSR listing tables in

Yes I saw that which is what led me to believe my initial statement is true (specifically that the cycle/instret/hpmcounter[n] CSRs must exist and be readable in M-mode). I was seeking clarification

I believe the end of section 3.1.12 in the current Priv spec answers your questions when it says: "In systems with U-mode, the mcounteren must be implemented, but all fields are WARL and maybe

Hi, Could I check my interpretation of the specification with regards to implementing cycle/instret/hpmcountern? It's permissible for an implementation to make these non-accessible in U mode

Pointer-masking extension - On Monday, members of the ARC met with the J Extension Task Group to review the status of the proposed pointer-masking extension. - It is the sense of the ARC that the

The implementation has some latitude here, but implementations I’m aware of do hardwire all these bits to zero in that case. If the corresponding xcounteren bits are read-only zero, then

Hi there, For an implementation that does not support all 29 programmable HPM counters, what is the expected behavior of bits in mcountinhibit and xcounteren associated with the unsupported counters?

In this example, an address above 2^56 would access a vacant PMA region. Regardless of the outcome of the PMP check, accessing a vacant PMA region will cause an access fault. I think that you have a

With that clarification in place, the comparison of an incoming address against a range happens in the 64 bits space. On Thu, Jan 12, 2023 at 1:39 PM Abel Bernabeu via lists.riscv.org

The pmpaddr CSRs have WIRI bits at the top, suggesting to discard bits [63:56]. And when discarding bits, one should assume some value for the discarded bits... but there is however no mention of what

Does the RISC-V architecture require particular behavior when physical addresses outside the implemented range are used? Suppose for example that 56 bits of physical memory are implemented. Is an

Hi Krishna, I'm interested in that and any other unfinished work from the CMO TG, but did not have enough time available to try to lead/drive that effort (and still won't for at least the next few

The CMO TG completed and ratified what was referred to as phase 1 work at the time. Per RVI procedures, that TG was wrapped up and any new and further CMO efforts are expected to be pursued via a new

Cache maintenance operations roadmap suggests there are plans to add Cache Block Operations by Index. Has there been any decision if these will be added to the spec? If so, what will be the

Pointer-masking extension - The ARC proposed a meeting with the J Extension Task Group to discuss some specifics of the latest draft proposal. IOMMU - Discussed the ongoing rework of the IOMMU

Procedural - AR plans to write a spec-writing guide in early 2023. - No AR meeting next week. PLIC - Discussed PLIC public review feedback. Removing references to H mode is correct.

Guo, You're welcome for the presentation. No need to apologize for the delay in replying, this change isn't going to happen in the architecture in any event, so there’s no specific hurry here.

We can combine it with PMU to observe the system forward guarantee situation. e.g., If too many "1" failure codes exist, the cache contention is serious. If too many "2" failure codes exist, there may

Guo -- Thanks for the thoughtful reply. How would the system or software use the proposed differing return codes? -- John

Derek, Thx for sharing the presentation with us; I spent some time chewing. So the reply is late. --- The problems of qspinlock --- The Linux queued-spinlock utilizes the lock_pending and