Re: 32-bit accesses to mtime/mtimecmp under RV64


On Tue, Apr 21, 2020 at 12:24 AM Allen Baum <allen.baum@...> wrote:
more mtimecmp questions:
 - the spec says that an interrupt occurs is
       posted when the mtime register contains a value greater than or equal to the value in the mtimecmp register. 
but doesn't specify that it is *unsigned* greater than or equal.


On Mon, Apr 20, 2020 at 3:48 PM Andrew Waterman <andrew@...> wrote:

On Mon, Apr 20, 2020 at 3:28 PM David Kruckemyer <dkruckemyer@...> wrote:

On Mon, Apr 20, 2020 at 2:38 PM Andrew Waterman <andrew@...> wrote:

On Mon, Apr 20, 2020 at 11:32 AM David Kruckemyer <dkruckemyer@...> wrote:

On Fri, Apr 17, 2020 at 7:31 PM Andrew Waterman <andrew@...> wrote:

On Fri, Apr 17, 2020 at 7:00 PM Greg Favor <gfavor@...> wrote:
The mtime and mtimecmp registers are defined as 64-bit memory-mapped registers.  The priv spec says that - in RV32 - mtimecmp can be written as a pair of 32-bit registers.  Since this was made specific to RV32, is there an intended implication in the spec that in RV64 the system must support atomic 64-bit accesses to these registers?  Or is it allowable for only non-atomic 64-bit accesses to be supported (i.e. a 64-bit access by a CPU is performed as two 32-bit accesses out in the SoC where mtime/mtimecmp are located)?

The spec strongly implies by omission that 64-bit accesses are atomic for RV64, in that it gives an unusually detailed RV32-specific code example to cope with non-atomicity, but mentions nothing of the sort for RV64.  I will add the additional sentence that makes this implication explicit.

Put differently, must RV64 software not assume that a 64-bit load/store will atomically read/write the register.  (Note: ARMv8 explicitly says software must not make such an atomicity assumption for accesses to memory-mapped 64-bit registers.)

In general, this depends on the peripheral and the platform.  We aren't trying to preclude interfacing with legacy devices and buses, so of course some 64-bit accesses to some devices will either become non-atomic or signal some sort of error.  But it's really quite useful to be able to assume that 64-bit accesses are atomic when interfacing with more modern peripherals that use 64-bit addresses, so we definitely do not want to preclude that, either.

Asking this slightly differently (I think) to clarify....

With respect to mtime/mtimecmp, does an RV64 processor place constraints on the platform, or can the platform place constraints on the RV64 processor? If the former, the implication is that the platform must provide a way for the RV64 processors to access the registers atomically with a 64b load or store. If the latter, the implication is that the platform can require the RV64 processor to access the registers non-atomically with 32b loads or stores, a la RV32.

The second half of my answer was addressing the more general matter. For mtime and mtimecmp specifically, the spec is now clear: 

So the only constraint is that when a 64b naturally-aligned access is made to mtime/mtimecmp, the access must be completed atomically if the platform allows 64b naturally-aligned accesses to those registers? A platform is still allowed to signal an error on such accesses and to force an RV64 processor to access those registers with 32b loads and stores, right?

I think your interpretation of that sentence is accurate. FWIW, the insufficiently described Linux platform does assume such accesses are legal (more precisely, the various SBI implementations make that assumption).






Join { to automatically receive all group messages.