Re: Platform specification questions
On Sun, Dec 12, 2021 at 7:55 PM Anup Patel <anup@...> wrote:
On Mon, Dec 13, 2021 at 5:45 AM Vedvyas Shanbhogue <ved@...> wrote:
Since, both OS-A platforms with M-mode and M platforms need ACLINT
Here's a response from a different angle. MTIME matters to the SEE because it provides the timebase that is then seen by all harts in their 'time' CSRs (via the RDTIME pseudoinstruction). But if the initial OS-A platform specs are going to drop any M-mode standardization/etc., then it seems like the thing to do - from the SEE and OS-A platform perspectives - is to abstract MTIME as just the "system timebase that propagates to all harts and is seen by S/HS/U mode software in the form of the 'time' CSR" (just as the Unpriv spec does in its own words).
Whatever would be said about MTIME and tick period constraints (e.g. a minimum tick period) would instead be expressed wrt this abstracted timebase - which the Unpriv spec refers to as "wall-clock real time that has passed from an arbitrary start time in the past. .... The execution environment should provide a means of determining the period of a counter tick (seconds/tick). ...".
This separates out from the current OS-A platform specs the ACLINT MTIMER device as a standardized Machine-level implementation of the MTIME and MTIMECMP registers defined in the Priv spec.
Now, for systems that implement Priv 1.12 and the Sstc extension, and actually use the Sstc extension, then this can be the end of the story.
But for today's systems and for future systems that don't implement Sstc (unless all OS-A 2022 platform specs were to mandate Sstc support and eliminate any possibility of existing systems complying with at least the Embedded (i.e. old "Base") OS-A platform spec), they also need the SBI API that provides Supervisor timer functionality to S/HS mode (with M-mode using MTIME and MTIMECMP to provide that functionality). While this is also an SEE interface, talking about this does start to sneak up on talking about MTIME. But then again one could still abstract MTIME as the system timebase, and MTIMECMP as a timebase compare value.