1. Tech-Aia
  2. Messages

Re: Proposal for ACLINT MTIMER groups

Josh Scheid
 

On Fri, Jul 16, 2021 at 9:50 PM Anup Patel <Anup.Patel@...> wrote:

For the MTIMER devices in a MTIMER group, only the MTIME register is aliased whereas the MTIMECMP registers are real/physical registers. As-per current proposal, a read/write to an “aliased MTIME” of a MTIMER device will read/write the “physical MTIME” register of the MTIMER group.


And also that those are separate system addresses, or not?  That every MTIMECMP group has a "local" MTIME register, which is then designated as aliased or reference?


In examply#2, the “physical MTIME” register is not visible to software as a distinct MMIO register and software can write any “aliased MTIME” register to modify the “physical MTIME” register. I am okay to define “aliased MTIME” register as read-only (unless anyone has objections) but this would mean that “physical MTIME register” need to be exposed as a distinct MTIMER device with no associated HART (i.e. no MTIMECMP registers). Also, once software sees a MTIMER device with “aliased MTIME” register, it will never write to such register.


Why do aliased MTIME registers need to exist at all?  I think I can see why you want them in order to accommodate legacy SiFive CLINT devices, but future facing, aliased MTIME registers don't seem to provide any value, so why require them at all?

In example#3, the “mtimer,reference” DT property is only a HINT for software to choose a “reference physical MTIME register” when doing inter-group MTIME software synchronization. The “mtimer,reference” does not imply anything about HW root in a multi-socket system because there will be separate NUMA-related DT properties for describing topology of a multi-socket system.


It's supposed to infer that from also analyzing orthogonal NUMA information?  Why add that dependency instead of just simply having HW MTIME devices and noting for each HW MTIMECMP group which HW MTIME device is the reference?

The “time” CSR in a RISC-V HART is “user-level read-only” (i.e. URO) hence cannot be used for software-synchronization.


Right.  I'm not sure why this came up.

Also, it simply makes NO SENSE to have a MTIMER device without a MTIME register.


I agree that it makes no sense to have a MTIMECMP group with no linked MTIME value root.  But I fail to see the reason each group of MTIMECMP as a device needs to have a local MTIME value resource visible to SW.  SW just needs to know where to read/write that value (if ever there's a need) and which set of harts' MTIMECMP states are rooted in the same HW time value.
 

Both MTIME and MTIMECMP register impact the state of HART timer interrupt because values in MTIMECMP register are absolute values of MTIME register (counter).


Yes, that's in the ISA.   But the ISA just says there's some MTIME register somewhere and there's some MTIMECMP register (per hart) somewhere.  Even the notion of a group of MTIMECMP is simply for space efficiency in HW (rather than potentially consuming a page of address space per hart).

It is certainly okay define “aliased MTIME” register as read-only because software won’t use “aliased MTIME” register for synchronization so I will consider this aspect when updating ACLINT specification.

 

A more explicit “mtimer,aliased” DT property (instead of boolean DT property) which points to the MTIMER device having “physical MTIME” register only provides more details in the device tree and not much useful to software because software on a RISC-V HART will always read the “aliased MTIME” register from the MTIMER device associated with it.


I think one of my primary points is that the MTIMECMP groups that currently have an "aliased" MTIME register should just be defined to have no MTIME at all and instead should be able to directly reference the HW root MTIME resource that it uses.

Perhaps we're converging slowly enough that we should arrange an interactive discussion.

-Josh

._,_

Join {tech-aia@lists.riscv.org to automatically receive all group messages.