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

I may be dense (I won't take a poll on that though), but if a kernel can detect that it is in S-mode vs. VSMode, that sounds like a buggy virtualization scheme. The kernel should (appear to) be in

Hi Anup, > Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit. It doesn't

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

Thanks. I will update the P extension specification to use the vxsat CSR. Best Regards, Chuanhua

Yes, should share the flag. Code that has an outer check for saturation to check if re-scaling needed, won’t want to care whether it was caused by scalar or vector routine. Krste

Analogous to the F and V extensions sharing fflags/frm, I’d think that P and V would share vxsat/vxrm. The reasoning is slightly different from the floating-point CSRs; in that case, sharing the

P extension specification has defined a fixed-point saturation flag CSR. We need to allocate it officially in the user standard read/write address range. Should we use the same CSR for V and P

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

I'll chime in with support for setting aside a small allocation of supervisor and hypervisor CSR numbers for debug use (similar to the current small allocation of machine CSRs for debug use). While

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

Yeah, sure. : ) 发件人: Andrew Waterman [mailto:andrew@...] 发送时间: 2020年8月4日 16:58 收件人: zhaosiqi (A) <zhaosiqi3@...> 抄送: Anup Patel <Anup.Patel@...>;

It's good news we came to the same conclusions independently :)

Thanks for the clarification. It turns out that I was looking at an older code base. 发件人: Anup Patel [mailto:Anup.Patel@...] 发送时间: 2020年8月4日 16:48 收件人: zhaosiqi (A)

In that case, yeah, section 3 does not propose anything new. 发件人: Andrew Waterman [mailto:andrew@...] 发送时间: 2020年8月4日 16:40 收件人: zhaosiqi (A) <zhaosiqi3@...> 抄送:

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

hcounteren.TM is already defined this way, for exactly this purpose.

I see. This is new information for me though. The ‘that is’ in the current spec makes the sentence look like an reiteration of the functionality of the htimedelta itself. I totally didn’t expect

Yeah, my point is that the current definition of htimedelta already says what you want it to say about the time CSR. Reading the time CSR in VS-mode or VU-mode isn't required to trap, and it returns