Hi ARM experts,
I have a problem in using armv8 mmu in bare-metal system:
When using the 4KB translation granule, level 1 table which use D_Block convert VA to 1GB region PA.
In Armv8 ARM page D4-1744, table lookup starts at level 0.
Is the Level 0 table a essential step to map the PA?
May I bypass the level 0 table and do mmu conversion via level 1 translation table? In other words, directly fill the L1 table address in TTBR0 register.
Thanks!!
Hello,
Yes, this is possible, but you will need to correctly configure the translation regime in order for it to work.
A translation table is defined as occupying exactly one granule of memory, so at 4KB granularity each table occupies 4KB. Each entry in a table is a 64-bit descriptor, i.e. 8 bytes, so there are 512 entries per table in this case. As you mentioned, each entry in a 4KB granularity L1 table maps 1GB of memory. Therefore, a complete L1 table will map 512GB (512 entries * 1GB per entry).
So providing the size of your virtual address space is no greater than 512GB, you only need a single L1 table. If, however, your virtual address space is greater than 512GB, you will need a second L1 table, and at that point you will also need an L0 table in order to select between the two L1 tables.
The size of the virtual address space is controlled by the TCR_ELx.T0SZ field, with the size being defined (2 ^^ (64 - T0SZ)). A 512GB virtual address space is 39 bits, so the T0SZ field would need to be 25 or greater. Note that this concept can be taken further - If you reduce the size of the virtual address space to between 25 and 30 bits inclusive, at 4KB granularity the translation regime will actually start at level 2, so TTBR0_ELx will point to the base physical address of an L2 table in that case.
I hope that helps,
Ash.
Hi Ash,
So, if the virtual address space is 512G, and use 4KB granularity L1 table, are the 4K bytes enough for MMU table in this case? I mean that need only one L1 4KB table can mapping all 512G virtual space, and push this L1 table address to TTBR0_ELx, is it right?
One more question, does the number of T0SZ depend on the number of PARange of id_aa64mmfr0_el1 register in flat mapping case? For example, if PARange indicates the physical address is 40 bits (1TB), must the T0SZ filed be 24 in flatting mapping case? In such flat mapping case, if software can confirm it only access the low 1G virtual space, could i just use a L2 4K granularity table to map 1G low virtual space?
tristan wrote: So, if the virtual address space is 512G, and use 4KB granularity L1 table, are the 4K bytes enough for MMU table in this case? I mean that need only one L1 4KB table can mapping all 512G virtual space, and push this L1 table address to TTBR0_ELx, is it right?
tristan wrote:
Correct, providing you have correctly configured the SCTLR_ELx.T0SZ field to limit the size of the virtual address space to 512GB.
One more question, does the number of T0SZ depend on the number of PARange of id_aa64mmfr0_el1 register in flat mapping case? For example, if PARange indicates the physical address is 40 bits (1TB), must the T0SZ filed be 24 in flatting mapping case?
That depends on whether there is anything actually accessible in the top 512GB of the 1TB physical address space. Take for example the Juno ARM Development Platform board's memory map, which is 40 bits (1TB), but the top 512GB are Reserved. In this case, for flat mapping we can actually just limit the size of virtual address space to 39 bits (512GB), and then any attempt to translate a virtual address outside of this range will result in a fault.
However, a key thing to note here is that you would see an Address Size Fault as opposed to a Translation Fault. If you would want virtual addresses in the top 512GB to cause Translation Faults then you would need to make the virtual address space also be 40 bits, and then have an L0 table with the 1st entry being a table descriptor pointing to your L1 table, and the 2nd entry being a fault descriptor.
In such flat mapping case, if software can confirm it only access the low 1G virtual space, could i just use a L2 4K granularity table to map 1G low virtual space?
Correct, you could limit the size of the virtual address space to be between 25 and 30 bits inclusive, and that would allow TTBR0_ELx to point to an L2 table. Although keep in mind that what I said above also applies here; virtual addresses in the top 999GB will cause Address Size Faults as opposed to Translation Faults. If this matters to you then you'll need to match the sizes of the virtual and physical address spaces and then use fault descriptors where necessary.
Thanks a lot, Ash!
View all questions in Cortex-A / A-Profile forum