How is Physical Address Width determined?

[SiFiveHolland]

The description of mttp contains this paragraph:

The MTTPPN refers to an MTTL3 table or an MTTL2 table based on physical address width (PAW). For 56 >= PAW > 46, MTTL3 table must be of size 2^(PAW-43) bytes and naturally aligned to that sized byte boundary. For 46 >= PAW > 32 the MTTL2 table must be of size 2^(PAW-22) bytes for Smmtt46 and Smmtt34, and must be naturally aligned to that sized byte boundary. In these modes, the lowest two bits of the physical page number (MTTPPN) in mttp always read as zeros.

This paragraph seems to imply that the top-level table (MTTL2 or MTTL3) is variably-sized, such that it only covers the part of the physical address space actually in use on a platform. For example, on a system with 2 GiB of DRAM, the largest valid physical address may be below 2^32. In that case, the MTTL2 may contain only 128 entries. I think this is an important feature to avoid wasting 16 MiB of DRAM on an MTTL2 when such a large table is not needed.

However, the description of the MTT walk algorithm does not describe any bounds check when accessing mpte. This can lead to out-of-bounds reads of the MTT. There needs to be a way for M-mode software to specify or at least detect the physical address width, so it knows how large of an MTT to allocate.

[SiFiveHolland]

Similarly, what happens if I try to use a physical address >= 2^46 in Smmtt46 mode, or a physical address >= 2^56 in Smmtt56 mode (possible with Svbare)? The current algorithm given in section 4.2 would ignore the upper bits, so the MTT lookups would alias with lower addresses. I would expect this to raise an access fault.

[rsahita]

see PR #88

[SiFiveHolland]

PR #88 adds a bounds check, but it does not specify how the bound is determined. If software does not know the bound, it cannot take advantage of it to use a smaller table.

[ved-rivos]

The bounds would need to be determined using platform specific mechanism. For instance the machine mode code that sets up the SoC fabric, trains memory controllers, and sets up the PMAs will be able to provide the bounds. Such bounds must be already known to machine mode software as that information about what are the bounds of the memory are needed to establish the PMP.

[SiFiveHolland]

The bounds would need to be determined using platform specific mechanism. For instance the machine mode code that sets up the SoC fabric, trains memory controllers, and sets up the PMAs will be able to provide the bounds.

OK, I suppose that could work. My hesitance comes from the perspective of the person writing that M-mode software: if the method for determining the Physical Address Width is entirely arbitrary, can I be sure the SoC manual will provide enough information to derive the PAW? There's no guarantee the PAW will correspond to any particular information in (for example) the SoC memory map, or the upper bound of detected memory (consider memory hotplug). And then this information must be communicated from the platform initialization code to the M-mode runtime services through (presumably) the devicetree.

Such bounds must be already known to machine mode software as that information about what are the bounds of the memory are needed to establish the PMP.

Yes and no. Many existing platforms rely on the hardware to reject accesses to addresses outside the bounds of physically-present memory, so they set up PMPs with a default-allow rule for the entire MXLEN-bit address space. So they may not track the bounds in software.

[rsahita]

PR #88 is now merged.