ARMv8 mmu problem

Hello,

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?

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.

I hope that helps,

Ash.

Hello,

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?

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.

I hope that helps,

Ash.

Thanks a lot, Ash!