Hi Alan, My statement “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” is because: Linux PMU updates counter value in-frequently only in start() callback The SBI_PMU_COUNTER_S

The “bypass-sbi” DT property will break QEMU virt machine for KVM because same QEMU virt machine is used with both TCG and KVM acceleration. This is yet another work-around for doing things differentl

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

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

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

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

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

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

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, 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 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 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 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, 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

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

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

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

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