Good catch. I agree with the problem and solution. I'll at least ask, though: could the Hypervisor host side-step this problem entirely by only "providing" relaxed-ordering IO regions to the guest?

John Hauser and I spoke about this topic tonight. We thought it useful to divide this problem into two cases: first, where the I/O access is trapped and emulated by the hypervisor, and second, the

Hi all, The FENCE instruction exposes the difference between accesses to main memory and accesses to I/O devices via the predecessor and successor sets; however, the distinction is really only defined

The Debug Spec has a count inhibit control bit already -- See the stopcount field in dcsr. Ernie

Good question. A couple of quick thoughts: - D-mode is not a required part of the Debug spec, i.e. a fully compliant implementation of the full Debug spec may not use an "execution-based" approach

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