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) <zhaosiqi3@...>; Andrew Waterman <andrew@...>
抄送: tech-privileged@...
主题: RE: [RISC-V] [tech-privileged] RFC: Dedicated Clock Source and Clock Event Source for HS-mode and VS-mode

 

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 emulate these CSRs because on real SiFive Unleashed TIME CSR is trap-n-emulated by M-mode.

 

Also, (like Andrew already mentioned) the MCOUNTEREN.TM and HCOUNTER.TM bits handles the delegation of TIME CSR properly.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of zhaosiqi (A) via lists.riscv.org
Sent: 04 August 2020 13:59
To: Andrew Waterman <andrew@...>
Cc: tech-privileged@...
Subject: 答复: [RISC-V] [tech-privileged] RFC: Dedicated Clock Source and Clock Event Source for HS-mode and VS-mode

 

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 this added bit of information about the changing of the trapping rule of the time CSR in there. (Judging from the current implementation in QEMU and KVM, reading time CSR in a virtual machine does trap.) Perhaps add a note to clarify this point?

 

However, there is still one new bit. Our proposal says that the no-trapping behavior can be turned off, so that the hypervisor can choose to emulate the time CSR for a virtual machine. This can provide the flexibility for implementing simpler systems where the aliases or the htimedelta does not exist.

 

发件人: Andrew Waterman [mailto:andrew@...]
发送时间: 2020年8月4日 16:06
收件人: zhaosiqi (A) <zhaosiqi3@...>
抄送: tech-privileged@...
主题: Re: [RISC-V] [tech-privileged] RFC: Dedicated Clock Source and Clock Event Source for HS-mode and VS-mode

 

 

 

On Tue, Aug 4, 2020 at 12:46 AM zhaosiqi (A) <zhaosiqi3@...> wrote:

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 for a virtual machine, the value returned should be adjusted by the htimedelta CSR. That sentence is meant to state this requirement.

 

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 the value you want it to return.

 

 

发件人: Andrew Waterman [mailto:andrew@...]
发送时间: 2020年8月4日 15:34
收件人: zhaosiqi (A) <zhaosiqi3@...>
抄送: tech-privileged@...
主题: Re: [RISC-V] [tech-privileged] RFC: Dedicated Clock Source and Clock Event Source for HS-mode and VS-mode

 

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 returned in VS-mode or VU-mode."  In other words, reading the time CSR when V=1 does what you propose.

 

On Tue, Aug 4, 2020 at 12:25 AM zhaosiqi (A) via lists.riscv.org <zhaosiqi3=huawei.com@...> wrote:

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 a clock event source for HS-mode and VS-mode, respectively. We extended the current idea of the mtime and mtimecmp CSRs and combined with the current hypervisor extension to come up with new CSRs and aliases. Evaluations on QEMU show that the proposed extension leads to performance improvement.

 

The attached document details the proposal. Any comments are welcome.

 

Regards,

Siqi