search

riscv / riscv-isa-manual

RISC-V Instruction Set Manual
https://riscv.org/
Creative Commons Attribution 4.0 International
3.61k stars 624 forks source link

Is there an issue, a smaller value is updated to mtime register after software doing PTP like linux? #1656

Open lixiaogangkkk opened 1 day ago

lixiaogangkkk commented 1 day ago

Situation: As privilege spec mentioned, mtime is read-write memory-mapped register which also works at a RTC. so it's possible that software can do PTP and update mtime periodically. Question: If smaller value is returned in PTP, how would mtime to be updated? If mtime is updated immeidately, it would affects the read of time CSR from cores, which violate the definition and requirement in https://github.com/riscv/riscv-isa-manual/issues/1113.

gfavor commented 1 day ago

Updating mtime, whenever one does it, is going to be disruptive to the system, especially if jumping backwards in time by more than a very small amount. And when firmware changes or jumps mtime in any material way, that is change is going to propagate to all the time CSRs and result in a delayed change or jump in time values.

Either that needs to be avoided or needs to be done "carefully" enough such that there won't be any serious impacts. Jumping the timebase backwards that system software is using, irrespective of whether that is an RTC, or mtime, or something else that isn't RISC-V-specific, presents the same problem. And ditto for systems based on other architectures.

Now as far as the monotonicity and cross-hart synchronization requirements regarding RISC-V 'time', these will be inherently and unavoidably violated when software changes or jumps mtime (and indirectly all the time CSRs). But one can consider these requirements to only apply after mtime is written by firmware (and its value has propagated to all the time CSRs) - and up until firmware writes mtime again.

lixiaogangkkk commented 1 day ago

Updating mtime, whenever one does it, is going to be disruptive to the system, especially if jumping backwards in time by more than a very small amount. And when firmware changes or jumps mtime in any material way, that is change is going to propagate to all the time CSRs and result in a delayed change or jump in time values.

Either that needs to be avoided or needs to be done "carefully" enough such that there won't be any serious impacts. Jumping the timebase backwards that system software is using, irrespective of whether that is an RTC, or mtime, or something else that isn't RISC-V-specific, presents the same problem. And ditto for systems based on other architectures.

Now as far as the monotonicity and cross-hart synchronization requirements regarding RISC-V 'time', these will be inherently and unavoidably violated when software changes or jumps mtime (and indirectly all the time CSRs). But one can consider these requirements to only apply after mtime is written by firmware (and its value has propagated to all the time CSRs) - and up until firmware writes mtime again.

Since modifying mtime is suggested to be avoid/careful, why not to move RTC a separate device from mtime. (As most of other architectures like x86, has set RTC to be separate device from APIC Timer and TSC). Also, RTC can works at lower frequency than system clock source in most system designs.

gfavor commented 19 hours ago

Architecturally mtime is not tied to an RTC or any other time device in a system. Mtime is a separate and independent memory-mapped counter of its own that provides an architectural timebase in RISC-V systems.

The non-normative text in the Priv spec that seems to equate mtime as "the RTC" of a system is misleading.

@aswaterman Can we do a simple mod to that non-normative comment to avoid this implication that mtime and the RTC in a system are one and the same?