Last level cache and NUMA node cache events are not specific to per hart. Do not make them mandatory for per hart performance monitor events. Signed-off-by: Atish Patra <atishp@...> ---

Signed-off-by: Atish Patra <atishp@...> --- riscv-platform-spec.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/riscv-platform-spec.adoc

This version of the platform specification doesn't mandate M-mode requirements. However, it should specify M-mode access protection from lower privilege modes for platforms that do implement

As per the discussion in the mailing list, M-mode requirements should not be included in this version of the platform specification to allow platform vendors more flexibility in implementing

I agree. But that requirement is there already for a system that implements a 10 Mhz clock and has to suport 10ns resolution. If 10ns vs. 1ns is a really sticking point could we have two values

The specification says "synchronized to within one tick". If the time CSR is incremented one tick at a time, then, for every update, as long as one update propagates to all harts before the next

So an implementation that supports 100MHz clock would need to update the mtime by 10 on each tick to meet the 1ns granularity. In current spec a implementation that supports 10 MHz clock would need to

Considering the requirement that all time CSRs be synchronized to within 1 tick, setting a fixed resolution indirectly makes synchronization much more difficult for implementations that have a lower

I am not disagreeing to that. regards ved

Just to clarify what I was trying to say: Whether distributing a large time bus or a "smarter" small time bus - which are functionally equivalent (and many designs I'm aware of do the latter),

Agree. Standard protocols like IEEE 1588 may also be used to acheive fine synchronization with a distributed time. Having distributed but synchronized time may avoid needing to send a large time bus

I agree that there are established time synchronization techniques, although where they are used today, they don't achieve or try to achieve 1ns accuracy. Taking a constrained example within a single

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

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

Given that the device-tree mechanism is apparently already in place, it honestly probably wouldn't be a big deal to just formalize that and not require any particular mtime resolution. I still prefer

It is late in my timezone, so please excuse that I respond only to the part that I feel is most critical to drive this forward. Well said and no disagreement there. In fact, I have suggested to the

Philipp, I am aware of the history of the platform working group / task group / subcommittee, as I have been regularly attending meetings since its inception in 2019, although I have a different

Linux discovers the timebase from device-tree and does not assume a fixed frequency: https://elixir.bootlin.com/linux/latest/source/arch/riscv/kernel/time.c#L14 regards ved

Yes. This gets to the heart of the difference between resolution and update frequency. For a given resolution one is free to update (with +1 increments) at an update frequency corresponding to the

I see what you mean. I was sort of mixed up by the term "default" as not normative. Does the timebase frequency being enumerated not suffice for the platform to convert time to ticks? regards ved