riscv-non-isa / server-soc

The repo holds the draft non-ISA Server SoC specification being developed by the Server SoC specification TG and to release intermediate releases of the specification on milestones. Further downstream this repo will be used to release specifications for public review.
https://jira.riscv.org/browse/RVG-58
Creative Commons Attribution 4.0 International
19 stars 6 forks source link

Memory Access Rules #13

Closed ShawnLess closed 11 months ago

ShawnLess commented 11 months ago

Hi, all:

Based on previous experience, it is quit annoying when system hung without further indications. In most case system hung because the CPU access a preserved memory ranges and no response is returned at hardware level (e.g., AXI response).

Though we can exclude unpopulated memory regions in memory map or PMA, but sometimes the "holes" in ranges makes the MMU table very complexed. And sometime speculative memory access can accidentally overpass these tables and leading to unexpected memory access, lead the system lockdown.

If we can ensure that every memory access must respond within finite time, e.g., for memory holes, return all 0's or return data abort exceptions to notify core that an unwanted memory access has occurred, then it will be much easier to setup all the memory map.

Does this make sense?

ved-rivos commented 11 months ago

This is a generalization of the PMA rule. The PMA provides attributes to all memory regions - including vacant memory regions. Vacant memory regions are also classified as I/O regions but with with attribute specifying that no accesses are supported. Following the Priv. architecture, accesses to such vacant regions should lead to an access violation exception.

ShawnLess commented 11 months ago

I agree with that PMA or MMU table can specify all of the memory region attributes, but this relies on a highly accurate PMA or MMU Table.

In some case, e.g., baremetal environment in early silicon bringup on emulation platform, setting up a full fledged PMA rules for every peripherals would take too much effort and time (emulation time) and make early bringup a more complexed workload. Another case is the PCIe related IO space, such as ECAM or MMIO, for which if no devices are mapped to the space, memory access should return all F's other than hanging.

I think this is not a PMA rule, but a feature that facilitate software debug. And should be easy to be implemented in hardware: for any unmapped address space, there should be a default slave to return error or default response to the request.

ved-rivos commented 11 months ago

The point I was trying to make is that the RISC-V ISA requires all memory to be specified using a PMA. A PMA may be a vacant PMA in which case the ISA would require an access fault. The Server SoC requirements are for privilege mode S and above - what operating system and hypervisors would observe. The SoC requirements do not extend to M-mode which would typically be required to establish the PMA. Such debug features can be incorporated in the SoC but they are outside the scope of this specification. If a memory returns all 0 or all 1 - then that memory exists as a read-only all 0 or all 1 memory. For the PCIe ECAM and MMIO - the rules in ECM_100 and MMS_040 - address the handling of devices that are not mapped or otherwise not available - but these memory ranges are not vacant as they are reported to the OS as memory designated for ECAM or MMIO and would have I/O memory region PMA.

ShawnLess commented 11 months ago

I see. If we only targeting the privilege mode S and above, this makes senses.