Re: MTIME update frequency
On Wed, Nov 17, 2021 at 04:37:21AM +0000, Anup Patel wrote:
Before we go ahead and change the MTIME resolution requirement in the platform spec, I would like to highlight following points (from past discussions) which led to mandating a fixed MTIME resolution in the platform spec:So synchronizing time between hart, dies or multiple sockets is an engineering problem. The architecture should not restrict the implementation to achieve the 1ns resolution. Synchronizing such counters even at much higher frequencies has been acheived in several implementations.
I find Lamport's paper http://lamport.azurewebsites.net/pubs/time-clocks.pdf is a good reference on this topic of time, clocks and ordering of events in a distributed system. The goal of such synchronization would be for the the system to acheive the property that - if an event a occurs before event b then a should happen at an earlier time than b. If that needs bounding to 1 tick or bounding to the latency of a fastest hart-to-hart transfer should be an engineering problem.
Once the resolution is determined I am not sure the upper bound on update frequency needs to be bounded.Of course its not very useful for an implementation have an update frequency higher than the resolution and implementations could pick the increments per update as the ratio between 1G and the implemented clock (instead of ration between 100M and implemented clock as in current draft).
2. It is common in enterprise clouds to migrate a Guest/VM across different hosts. Considering the diversity in RISC-V world, we have to support migration of Guest/VM from host A to host B where these hosts can be from different vendors. Now if host A and host B have different MTIME resolution then Guest/VM migration will not work and this problem also applies to ARM world. This is another reason why ARM SBSA mandates a fixed timer resolution. Although, ARM world standardized timer frequency quite late in the game but RISC-V world can avoid these problems by standardizing MTIME resolution quite early. Alternatively, there is also SBI para-virt call possible to detect change in MTIME resolution but this would mean additional code (along with barriers) in the path of reading time CSR (as an example, look at KVM para-virt clock used in x86 world).If we do want to fix the resolution then the 10ns is too coarse. I suggest we make it at least 1ns to address the requirements of systems many of us are building. With 10ns resolution it will not be competitive against ARM systems that as you noted have fixed resolution to 1ns or x86 where TSC operates at P0 frequency.