K3 mhpmeventX Registers: Virtualization Bits VSINH and VUINH Under Test

The SpacemiT K3 implements the RISC-V privileged architecture with a rich set of hardware performance monitoring counters. A recent forum post (Topic #1644) reports a careful test of the upper bits of mhpmevent3, asking whether the VSINH and VUINH fields described in the RISC-V privileged specification are actually wired up in the K3 silicon.

Background: mhpmevent CSRs

RISC-V defines a set of machine-level counter-event selector CSRs named mhpmevent3 through mhpmevent31. These CSRs control which events increment the corresponding mhpmcounter registers. The high bits of each mhpmevent CSR can act as event filters:

• OF (bit 63): overflow interrupt enable
• MINH (bit 62): inhibit counting in M-mode
• SINH (bit 61): inhibit counting in S-mode
• UINH (bit 60): inhibit counting in U-mode
• VSINH (bit 59): inhibit counting in VS-mode (virtual supervisor)
• VUINH (bit 58): inhibit counting in VU-mode (virtual user)

The VSINH and VUINH fields matter for virtualization-aware profiling and for any hypervisor that wants per-VM performance attribution.

What the Community Test Found

The author wrote values that set each filter bit in turn and observed which bits were retained by the hardware. The results posted on the SpacemiT forum are:

• OF, MINH, SINH, UINH: implemented as specified.
• VSINH and VUINH: not implemented on the tested K3 device; writes to these bits are ignored (read back as zero).

This means K3 performance counters can distinguish between M, S, and U privilege levels, but they cannot currently separate counts that occur in a virtualized guest from counts that occur in the host.

Implications for Profiling and Virtualization

If you are writing a hypervisor or a profiling tool for K3, you should not rely on VSINH/VUINH for automatic guest/host filtering. Two practical alternatives remain:

1. Context-switch the mhpmevent selector on VM entry and exit. This adds a small amount of overhead but gives accurate per-VM counts.
2. Use the MINH/SINH/UINH fields together with the existing privilege state, accepting that guest-supervisor and guest-user events will be grouped with host-supervisor and host-user events respectively.

For bare-metal or single-kernel use, the limitation is transparent: M/S/U filtering works as expected.

A Quick Reference Snippet

To test the filter bits yourself from M-mode:

csrr t0, mhpmevent3 li t1, (1 << 63) | (1 << 62) | (1 << 61) | (1 << 60) | (1 << 59) | (1 << 58) csrs mhpmevent3, t1 csrr t2, mhpmevent3 and t2, t2, t1 # bits that read back as 1 are implemented

On K3, expect t2 to contain bits 63 down to 60 set, while bits 59 and 58 remain clear.

Relation to the K3 Ecosystem

The SpacemiT K3 is marketed as a RVA23-compliant AI CPU with eight X100 application cores and eight A100 AI cores. Understanding which privileged-architecture features are silicon-complete helps developers set realistic expectations for porting hypervisors, profilers, and OS-level tooling. At open-riscv.com we cover these micro-architectural details alongside higher-level software porting guides for K1 and K3.

Source: K3 mhpmeventX寄存器的VSINH/VUINH域是否实现