mmuarmv8

How to understand the ARMv8 AArch64 MMU table descriptor format in the diagram?

The diagram below is taken from ARMv8-A Programmer's Guide:

Armv8-A programmer's guide

I am a bit confused by the highlighted entry type. Let me state my current understanding first (suppose the scenario of a stage 1 translation in EL3 with granule size 4KB).

In the first place, it seems that the name "entry" and "descriptor" is interchangeable in this context.

Then, according to ARM ARM doc (e.g. Figure D5-6), it seems that there are 3 types of valid descriptors:

There are also several constraints (w.r.t valid descriptors), namely:

So back to the diagram above, I don't understand why there is another Table entry for L1 and L2? Because the 1st line in the diagram depicts table descriptor for L0/L1/L2 already. Then, even if this is another table descriptor type, why the middle content is marked as "Output block address" (instead of "Next level table address")?

Solution

  • I think I see where you're stuck, this was a pain for me to understand too.

    In the first place, it seems that the name "entry" and "descriptor" is interchangeable in this context.

    This is not true. A table descriptor points to another table. A table entry points to a data page. Since it is not valid to have a table entry in L0/L1 (dependent on the granule) nor a table descriptor in L2, ARM is actually able to re-use the same encoding to mean two semantically different things. This means that your desire to distinguish between D_TABLE and D_PAGE is sorta murky since what actually determines what type PTE[1:0] actually is comes from the context PTE is coming from (L0/L1? it's D_TABLE! L2? it's D_PAGE!).

    This is kinda a pain for us as software people but it really helps on hardware implementation since it means that they can re-use all the same decoding logic for both descriptor and entry results. If you're an optimistic type, you can think about this though as ARM letting you use the same format for generating both table links and page entries which can ease the implementation a bit haha.

    So back to the diagram above, I don't understand why there is another Table entry for L1 and L2?

    So, why do we have two? It's mainly that although descriptors and entries share most of the same encoding, entries support things that descriptors do not. Namely, all of the stuff in the "lower attributes" field (stuff like sharability, fine grained access permissions, MAIR, etc.) that don't generally make sense to apply hierarchically from a page table (what MAIR would you apply if L0 says one thing and L1 says another??)