riscv-software-src
rv64mi/access.S
This test admittedly makes some assumptions about the platform memory map, but: physical addresses in RV64 are, in practice, limited to 56 bits, because the page-table entry format only supports 56-bit physical addresses. So flipping bit 63 should cause an access exception in practice.
Thanks for the explanation., but it seems to me that the tests like that are at odds with generality of compliance tests. What if one does not implement virtual address translation?
I agree with you in principle, but it seems contrived to have a system without address translation that also supports such a large address space.
How should I then interpret this sentence in user manual: "A RISC-V hart has a single byte-addressable address space of 2^XLEN bytes for all memory accesses"
if it is implicitly assumed that it cannot be beyond 2^56?
That's the unprivileged view of the system. The privileged architecture can impose additional constraints on the memory map. For example, when Sv39 virtual memory is enabled, only 2^39 bytes of address space are accessible.
I'd argue these implementation assumptions should be removed from the conformance tests. If an implementation wants to disable address translation and put memory mapped registers way up in the address space, the conformance test shouldn't flag that as a failure.
If a vendor building RISC-V processors does produce an address map where instruction fetch from an address >= 2^63 is supposed to succeed, they are free to submit a pull request that fixes this assumption in a clean way. This is too hypothetical to bother fixing preemptively.
PS. It may be the cleanest solution is simply to not run this test if it doesn't apply on a given platform.