riscv/riscv-isa-manual

Can the value of time CSR be a lagged value of mtime?

zhuotianshu opened this issue · 7 comments

zhuotianshu commented

Suppose that I modify mtime first, then fence io, then RDTIME, is it possible to read a value before the modification?
Suppose that I read mtime first, then fence io, then RDTIME, is it possible to read the time value smaller than the mtime?

gfavor commented

No and No. As the CSR Access Ordering section in the Unpriv manual says:

These CSR-ordering constraints are imposed to support ordering main memory and memory mapped I/O accesses with respect to CSR accesses that are visible to, or affected by, devices or other harts. Examples include the time, cycle, and mcycle CSRs, in addition to CSRs that reflect pending interrupts, like mip and sip.

Since mtime would be memory-mapped in an I/O PMA region, and CSR accesses are classified as I/O accesses for fence purposes, "fence.io" would provide the desired ordering.

zhuotianshu commented

OK, that's clear.

gfavor commented

I should clarify my prior post:

  • A Fence only orders the accesses, not the side-effects (especially where 'time' CSRs reflect a "delayed" version of mtime).
  • Note that a write to mtime gets reflected into things like MTIP eventually, and similar is true for mtime getting reflected into 'time'.
zhuotianshu commented

I should clarify my prior post:

  • A Fence only orders the accesses, not the side-effects (especially where 'time' CSRs reflect a "delayed" version of mtime).
  • Note that a write to mtime gets reflected into things like MTIP eventually, and similar is true for mtime getting reflected into 'time'.

OK, that really answered my question. I also opened an issue in AIA repo riscv/riscv-aia#82 about the speed of generating side effects of CSRs, especially about:

  1. the speed of *topei to change the *topi
  2. the speed of *topi to generate a trap
  3. the speed of VGEIN to change vstopei, and its effect on "barrier" interrupts of last guest interrupt file

In the privilege specification, there is a discussion about the side effects of explicitly writing to m/sip, m/sie, m/sstatus, and m/sideleg on generating interrupts. However, in the hypervisor chapter, there is little discussion on this topic. Are there any default rules that allow the side effects of CSRs to be delayed if not otherwise specified?

zhuotianshu commented

I should clarify my prior post:

  • A Fence only orders the accesses, not the side-effects (especially where 'time' CSRs reflect a "delayed" version of mtime).
  • Note that a write to mtime gets reflected into things like MTIP eventually, and similar is true for mtime getting reflected into 'time'.

OK, that really answered my question. I also opened an issue in AIA repo riscv/riscv-aia#82 about the speed of generating side effects of CSRs, especially about:

  1. the speed of *topei to change the *topi
  2. the speed of *topi to generate a trap
  3. the speed of VGEIN to change vstopei, and its effect on "barrier" interrupts of last guest interrupt file

In the privilege specification, there is a discussion about the side effects of explicitly writing to m/sip, m/sie, m/sstatus, and m/sideleg on generating interrupts. However, in the hypervisor chapter, there is little discussion on this topic. Are there any default rules that allow the side effects of CSRs to be delayed if not otherwise specified?

Could someone give an answer or suggest about this?

gfavor commented

John Hauser (the lead author/architect of AIA) just answered an earlier version of the same question - posted as a GitHub issue for AIA: riscv/riscv-aia#82