Does the spec require physical addresses to be canonical?

[Roger Espasa]

Elevating this question to isa-dev.

The question came up from this test: https://github.com/riscv/riscv-tests/blob/master/isa/rv64mi/access.S, which creates an address with bit 63 set and then jumps to it, expecting an access fault. 

The question is:  *why* is this address illegal in M-mode? 

a) because M-mode physical addresses must be canonical (does the spec explicitly say that?)

b) because the test does not expect any actual implementation to have 64b physical addresses?

c) other?

Andrew Waterman provided an initial answer:

I'll make the argument that the spec implicitly requires them to be canonical, because in the intro we say that a hart sees a full XLEN-bit address space, and in the priv spec we say that any address is either memory, I/O, or vacant.  This definition doesn't appear to admit the possibility of unchecked address bits.

With that said, I suppose it's legal in principle to say that you've chosen to alias the physical address space 2^(XLEN - implemented physical address bits) times, which is roughly equivalent to not checking the upper address bits.

Comments?

Thanks

roger.

[Allen Baum]

More generally, I'd call that aliased address space.

It wouldn't be unusual for a specific region to have unchecked bits, within the region (e.g. IO devices on 4K boundaries, but only a few registers, and the set of registers is aliased many times within that space).

This is taking it to an extreme, but even there just because that specific address succeeds/traps doesn't mean some other region will have the same behavior if A[63] os flipped. 

I had intended for the arch-tests to define the actual physical address length - that's needed for some TVAL tests.

Having said that: SV39/48 (and I assume SV57) PTE format only has 56 bits of physical address.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAD%3DxdLhFq%2BGmJ54cpOMcHzLsYgXXxdw1h5tz2V2C9Zz7-1-35Q%40mail.gmail.com.

[Greg Favor]

Architecturally PA's can be full 64-bit implemented values (i.e. the hardware computes and does something with all 64 bits).  Or, more commonly, only the low N bits are implemented (and are zero-extended into official 64-bit PA's).  From Allen's perspective, the "actual PA length" would be 64 in the former case and <64 in the latter case.

The hardware computes all 64 bits of an address (see below) but typically otherwise doesn't do anything with the "unimplemented" high bits (leading typically to an appearance of address aliasing).  Full 64-bit zero-extended PA's only appear in registers.  Past the address ALU, downstream address datapaths only need to be N-bits wide.

Where an exception can come into this picture is when PMAs and/or PMPs are implemented (conceptually right after computing the full 64-bit address value).  Any PMA or PMP access/permission violation would result in an Access Fault exception.

So if one computes a 64-bit PA with bit 63 set, then it is up to a PMA or PMP check to flag this address as inaccessible in some manner.  Typically, for "actual PA length"=N (<64), there would be an implicit or hardwired PMA that matches all computed PA's >= 2^N, treats that as a "vacant" region, and causes an Access Fault exception.

Greg

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DBK6oQsNW0ezd%3DGRLkVYBbqFuxOCbui_HLCSCX7bOD42A%40mail.gmail.com.

[Samuel Falvo II]

Looking back at some historical cases would be enlightening as to why, I think.

One I'm most familiar with, the Motorola 68000 processor implements a 32-bit instruction set, with 32-bit wide data and address registers.  Effective addresses are always computed to 32-bits of precision.

However, the physical hardware only implements 24 bits of physical address space.  The upper 8 bits were simply truncated from the effective address before being presented on the bus.

As a result, clever software developers decided to use the upper 8-bits of a pointer for flags.

This has affected both Apple Macintosh and Commodore-Amiga software.  I'm unaware of it affecting Atari ST, but it's conceivable that, at some point, that it did for that platform as well.

Software worked fine until, one fateful day, someone decided to implement a 68020 accelerator card for these systems.  In the Amiga's case, while the kernel booted up fine, running some software (e.g., AmigaBasic for example) would occasionally crash.  This is because the 68020 exposed all 32-bits of an effective address to the external bus, and with enough RAM populated, it would lead to memory corruption.  Those systems which made use of an 68851 MMU would end up crashing consistently, due to page faults from unmapped memory.

Needless to say, it didn't take long for some vendors to realize the problem and fix the software.  But, still, that patches were necessary meant that a lot of companies had to invest in newer, 32-bit-clean versions of their software.  For other companies, the investment was deemed insufficiently profitable, and (e.g., as with AmigaBasic) was never updated.  To this day, I still don't think a 32-bit clean version of AmigaBasic exists.  The only safe way to run it on a 68020 or better CPU is to (1) ensure only 8MB of RAM or less is installed, and (2) make sure the PMMU is disabled.

RISC-V is in the unique position to advocate, if not standardize, the default semantics of using upper, unexposed address bits for things like flag bits; namely, that your software will trap when an access is made.  This will ensure forward compatibility with later processors which does expose more physical address bits on the bus.  It'll also dissuade developers from using unused bits as flags or tags, just because it's convenient.  Doing so will, as history shows, cause pain in the future.

On Tue, Mar 2, 2021 at 4:26 AM Roger Espasa <roger....@semidynamics.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAD%3DxdLhFq%2BGmJ54cpOMcHzLsYgXXxdw1h5tz2V2C9Zz7-1-35Q%40mail.gmail.com.

--

Samuel A. Falvo II

[Allen Baum]

To add noise and confusion to this: ARM TopByteIgnore and the proposed RV PointerMasking proposal which can configure dynamically which address bits are ignored, and replace them with a default value so they can be used as tags, or can support sandboxing.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsonHmhQdEAgHk9MfRtY9wTAze4r7pgGdyqOSipKeBxe8qw%40mail.gmail.com.

[Roger Espasa]

Note that I am not advocating a particular position, but rather seeking clarification in the spec writing. 

I myself would tend to agree with this comment from Greg:

So if one computes a 64-bit PA with bit 63 set, then it is up to a PMA or PMP check to flag this address as inaccessible in some manner.  Typically, for "actual PA length"=N (<64), there would be an implicit or hardwired PMA that matches all computed PA's >= 2^N, treats that as a "vacant" region, and causes an Access Fault exception.

But then, the test mentioned in my first post should be either (a) removed from a compliance suite or (b) made dependent on same implementation-dependent parameter (i.e. IMPL_PA_BITS).

In any case, I would suggest the spec actually says something about whether checking the PA upper bits is "left to the implementation's PMA/PMP"  or "must be canonical based on the implementation PA size". 

[Allen Baum]

For what it is worth: the ISA spec gives wide latitude for options.

The PMA has one of the widest, and it's hard to even parameterize its functionality, much less the chosen options for the purposes of testing.

Technically, the way the spec is written, there are multiple PMAs:

     MainMemory versus I/O versus Vacant Regions

     SupportedAccessType

     Atomicity (subtypes  AMO, Reservability, Alignment)

     Memory-Ordering

     Coherence and Cacheability

     Idempotency

I have a proposed framework for defining generic PMAs for the purpose of architectural testing, available here

which describe the parameters required to be defined for every distinct address range.

The max address of non-vacant address ranges defines the PA width.

[Fedor Borisovskii]

Hello,

May I enter this conversation?

I found this conversation is connected to other extensions and specs

(debugging and tracing for example).

And it creates uncertainty in implementation of memory access

traps, triggering and debugging.

Over here 3 possible implementations were mentioned

1 - alias the physical address space 2^(XLEN - implemented physical address bits) times.

2 - ..implicit or hardwired PMA that matches all computed PA's >= 2^N, treats that as a "vacant" region, and causes an Access Fault exception.

3 - RISC-V Pointer Masking

Am I right that there is no documented suggestions of how to manage PA width <= XLEN?

And there is no CSR that maintains what mechanism is implemented?

Omitting RISC-V Pointer Masking the situation is ambiguous.

Is there mechanism to discover PMA ranges and aliasing properties?

I see that aliasing is bad in any case.

So I agree that AF at PA overflow is good.

Regards,

Fedor

четверг, 4 марта 2021 г. в 08:54:29 UTC+3, Allen Baum:

[Michael Chapman]

You should add no. 4 which is that read accesses for addresses out side the implemented range return 0 and writes do nothing. This is preferable to mirroring and aliasing different addresses to the same physical location. This occurs often in peripherals which have bits or words in their address space which are unused or reserved for bigger versions of the same peripheral.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f1e8e291-d8ae-40eb-8f17-434d87165644n%40groups.riscv.org.

[Allen Baum]

good point - you could do a silent WARL0 treatment.

But, in any case, PA mappings are done in the PMA which at one level is architecturally defined (what the parameters are for each range) - but that's all.

What the ranges are, and their exact characteristics, is completely implementation defined.

Architecturally, there is no way to discover what those parameters are.

I have a proposal to codify those parameters located here - but it is an informal proposal, and not sanctioned or defined by RISC-V.

And, it merely defines the structure, and says nothing about how that structure can be queried.

Probably this is something that is discovered at the platform level (e.g. through device tree) rather through some architectural mechanism or other. - which makes sense.

In addition, I would expect that there will be custom parameters, and configurable parameters that go beyond this tal=ble.

I know we do.