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

You seem to be missing the whole point: the x86 PerfMon/ EMON event filtering is generic. Ditto for Intel: in fact, x86 PERFEVTSEL has precisely an 8-bit field to select which

A general comment about all the fancy forms of event filtering that can be nice to have: The most basic one of general applicability is mode-specific filtering. Past that one could try to define some

I meant "that's one of the reasons why P6's original performance monitoring interrupt was imprecise" darn that speech misrecognition: sometimes it inverts the meaning of what

x86's hardware performance monitoring interrupt is delivered to whatever is specified by the local APIC's LVT (Local Vector Table) entry for performance monitoring. This gets it out of

Hi Andy, Thank you for the hints as an Intel PMU architect. My question is about the mode selection part as below. It is not difficult to implement such a mechanism that an event should only be

BTW, I have absolutely no idea what changes would be necessary to the RISC-V HPM CSRs. I do note however that the x86 control bits pretty much lived in one CSR per counter.

I have NOT been working on a RISC-V performance monitoring proposal, but I've been involved with performance monitoring first as a user then is an architect for many years and at

The preceding is true, but your following paragraph isn't quite true. In the current architecture spec one isn't free to hijack or reuse ASID=0 in the way I think you are describing. It might be

On 7/21/20 11:56 AM, Greg Favor wrote: I agree about calling M-mode. But I think the software that swaps entire mcountinhibit registers doesn't have to know anything about the bits in them

What I ultimately understood from Brian's email's is that this 'marked' bit conceptually is not a state bit associated with each counter, but a state bit maintained separately by software (as it

Brian, I think the advantages you explain are exactly the reason why I was asking whether the marked bit was a significant improvement. I think the functionality is extremely similar to swapping

My understanding is that sfence.vma's are never required by the RISC-V spec, only that failing to do them can cause undesirable but well defined behavior. I'd suggest that the same be true here. We

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

Regarding overflow interrupts as edge-sensitive interrupts: It seems like this would require that there not be any overflow status bit in mhpmevent CSRs (or any alternative CSR), otherwise this bit

Ah, I see. The 'marked' bit is state associated with and managed by the code running, not associated with a counter. Then a counter could be configured (via its event selection) to count a selected

It's late; I'm missing something. How is "mark" being set/cleared on entry/exit different than "active" in Greg's proposal being set/cleared on entry/exit ?

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 'marked bit' in my proposal is different from a per-counter active bit, and may be a bit hard to explain well, but I'll try. To me, there are two very different performance monitor approaches for

Hi, Alan. My proposal is still a work in progress, hence has not been shared publicly, but is significantly based on a proven architecture with about 30 years in the field and a few billion shipping