Another thought from one of my debug coworkers: what do we want to do about debug (D-mode)? Having a bit that says "inhibit counting when we are in D-mode" would allow debuggers to do accurate perfmon

Dang. I think that typo crept in at the last second. The bit numbering for the bottom three bits should be 58, 57, and 56 - resulting in the full top byte of mhpmevent being covered. Thanks, Greg

I noticed another typo that I don't think has been pointed out -- reuse of bit 59. bit [59] VSINH - If set, then counting of events in VS-mode is inhibited bit [59] VUINH - If set,

Hello, Thanks for raising this Arjan, it's been a low-priority item on my TODO list to open a discussion on bus errors for a while now (I work on Ibex amongst other things at lowRISC). I think RISC-V

Hi all, We want to add support for ‘bus errors’ in our RISC-V design (e.g. signaled via AXI bresp/rresp signals). I studied a couple of different RISC-V architectures and I do not see a common

I generally agree with Andrew. At the same time I'll also observe that, practically speaking, the AIA is coming soon and it very much directly interacts with the H extension. So waiting a little

In other architectures, those devices are needlessly complex in part because they weren’t co-designed with the ISA. Yes, they can be independently designed, but possibly with regrettable

On all major architectures (x86 and ARM64), the virtualization-aware interrupt controllers and IOMMUs are totally independent from ISA virtualization support. We already the required ISA support

* substantially greater utility Shouldn’t write emails on phone...

I’m not in support of freezing it yet. My concern is that development of virtualization-aware interrupt controllers and IOMMUs will lead to reconsideration of some of the details. All of these items

Hi All, The RISC-V H-extension v0.6.1 draft was released almost a year back in May 2020. There has been no changes in the H-extension specification since then. Meanwhile, we have RISC-V H-extension

Sure. I will send that once I have the detailed instructions available in public domain. -- Regards, Atish

congrats! can we send something out to tech-announce about it? -------- sent from a mobile device. please forgive any typos.

Awesome!

Hi, We are glad to announce that we are able to boot Linux in KVM guest on a FPGA (Rocket chip + H extension v0.6.1). We now have three hypervisors working on a Hardware with H extension. 1. KVM

Using 'hpm' probably would be a bit confusing. But I'll look into alternatives. Btw, since a new extension naming standard is being developed, ultimately this (and all other extensions) will need to

Given the discussions about cache-ops and the name for them on tech-cmo and the desire to avoid "co", "COF" (which can also mean "change of flow") may not be the best choice for the extension

You're correct. Standard mideleg functionality applies. I'll incorporate a clarification note. As you note, this starts getting into adding a number of bits and associated functionality. The

Could you clarify how this extension interacts with mideleg? I assume interrupt 13 would be taken in M-mode by default unless it is delegated to S-mode, but it would be nice to state this

One typo crept by me and some other pre-reviewers: scountovf contains shadow copies of the OF bits in the 29 mhpmevent CSRs (i.e. mhpmevent3-mhpmevent31). Greg