Re: Are pages allowed to cross PMA regions?

Andy Glew (Gmail) <andyglew@...>

But if that access straddles multiple pages and/or PMA regions, then each byte of the access must pass its MMU
| and PMA checks for the whole access to be allowed.

It would be nice if it was architecturally defined/permitted for such straddling accesses to be performed a byte at a time.   That makes the trap and emulate handler easier to code.

If not a byte at a time, then whatever is the largest  possible NAPOT size that the  access can be decomposed into.

But anything coarser grained than a byte,  or whatever the finest granule of PMA is,  either requires the trap and emulate handler to probe permissions to guarantee that  the transactions it emits are not themselves straddling,  or you have to be ready to handle nested such trap and emulations.   Or at least tail recursive.  

| <>

------ Original Message ------
From "Krste Asanovic" <krste@...>
To "Greg Favor" <gfavor@...>
Date 8/12/2022 12:57:55
Subject Re: [RISC-V] [tech-privileged] Are pages allowed to cross PMA regions?

On Fri, 12 Aug 2022 10:35:15 -0700, "Greg Favor" <gfavor@...> said:
| Can a virtual paged be mapped to addresses that cross PMA regions? For example, is it acceptable to map a 1GB page such that half its physical addresses have the (e.g.) cacheable
| attribute but the other half of physical addresses are uncacheable? You could think about this with every attribute: vacant, idempotent, etc.
| This sounds odd, but the ISA does not explicitly allow or forbid it. Is it something that must to be supported? If so, are there example use-cases?
| The PMA architecture allows a lot of implementation flexibility - including for example having small 4B regions.  In that example one could easily have one 4KB page overlap multiple
| PMA regions.
| Conversely, in a typical OS-A class system using demand-paged virtual memory, the implementor will probably choose to have a minimum 4KB granularity to PMA regions.  Although this
| still allows 2MB, 1GB, and 512GB pages to overlap multiple PMA regions.  (Which in typical TLB implementations leads to what some would call "atomization" of page mappings into
| smaller TLB entry mappings.)
Even in a RISC-V OS-A platform, the implementor might be stuck with
using IP peripherals where PMAs vary at the sub-page granularity.
| In short, if a page overlaps multiple regions, then that needs to be handled properly.  Typically any given load/store/ifetch/implicit access that is being checked will fall in one
| page and in one PMA region - in which case the behavior is obvious.  But if that access straddles multiple pages and/or PMA regions, then each byte of the access must pass its MMU
| and PMA checks for the whole access to be allowed.
We have some text for this in some places, but these concepts should
really be factored out somewhere central.

Join { to automatically receive all group messages.