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

Thanks for the timely comment, we are aware of the htimedelta CSR in the hypervisor spec. Section 3 is meant to propose aliases available in VS-mode and VU-mode. Because they are meant to provide time

Note that Section 3 of your proposal already exists. The hypervisor spec says, "The htimedelta CSR is a read/write register that contains the delta between the value of the time CSR and the value

Hello Everyone, We have come up with some ideas about improving the performance of virtual machines on the RISC-V architecture. Here’s the first piece which proposes a dedicated clock source and

Hi all, I am for bit[28]. I tried to defend the idea but unfortunately my reply goes private to Anup only, and the system doesn't leave any backup. Please wait and see my comment once Anup replies.

That reduces the argument for bit [31]. I won't remove it yet (until I write up an updated proposal), but I imagine that bit will be dropped if no one else speaks up in support of it. (Although