A clarification is required in RISC-V H-Extension spec regarding scope of HSTATUS.VTVM bit. Currently as-per the spec, all virtual memory management instructions (both SFENCEs and HFENCEs) will trap t

Hi Jonathan, All cases for CSR accesses have not been thought through (initial draft) and written out. Regarding WARL CSR with hardwired bits, the HW will always read/write fixed values of hardwired b

Hi All, We have updated QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6 spec. The QEMU repo with RISC-V H-Extension v0.6 support can be found here: https://github.com/kvm-riscv/q

This is not needed. We can easily probe number of PMP registers using illegal instruction traps. Look at latest OpenSBI sources. Regards, Anup

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it. All these software will: Either use illegal instructio

The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension. Currently M-mode runtime firmware (OpenSBI) does following to support H-extension: Emul

Hi All, The proposed SBI PMU extension is a set of APIs between M-mode and HS-mode (also between HS-mode and VS-mode) such that no RISC-V spec changes are required for existing HPMCOUNTERs. The high-l

Hi Greg, For per-HART edge sensitive interrupts, we can avoid the overflow status bit for each counter by keeping track of last read value and comparing this last read value in overflow interrupt hand

Hi All, We have updated Spike, QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6.1 spec. The QEMU RISC-V is our default development vehicle for RISC-V hypervisor software (because

Hi All, We now have a simple Nested MMU (i.e. Two-stage MMU) test-suite available as part of Xvisor white-box testing framework. This test-suite runs in HS-mode and does nested MMU testing using the H

Hi Greg, Few comments on your proposal (https://lists.riscv.org/g/tech-privileged/message/205): 1. The BIT[31] is not required because we already have MCOUNTINHIBIT CSR 2. The BIT[28] contradicts CSR

Hi Greg, We have SBI_PMU_COUNTER_START/STOP calls where the SBI implementation will update the MCOUNTINHIBIT bits. The SBI_PMU_COUNTER_START call also take parameter for initial value of counter so we

Hi Greg, No issues with Bit[31] of your proposed MHPMEVENT definition. The SBI_PMU_COUNTER_START/STOP calls can either update MCOUNTINHIBIT Bits or these calls can update Bit[31] of appropriate MHPMEV

The QEMU “virt” machine emulates both TIME CSR and HTIMEDELTA CSR so no trapping happens when accessing TIME and HTIMEDELTA CSRs from VS/VU mode on QEMU. Although, QEMU “sifive_u” machine does not emu

The most desired feature from a PMU is counting events in right-context (or right-mode). This is not clearly defined in RISC-V spec right now. Greg’s proposal already address this in a clean way by de

HI Alan, I never said HPM overflow interrupt is not important. The MHPMOVERFLOW CSR proposed by Greg is perfectly fine. I think you missed my point regarding H-extension. If S-mode is allowed to direc

Hi Alan, I think I am repeating myself here but still don’t see any benefit of allowing HPMCOUNTER CSR write access to S-mode. On the contrary, it will make context switching expensive for hypervisors

Yes, there is no way for kernel to know whether it is running in HS-mode or VS-mode. We would like to keep it that way. Regards, Anup