ARMv8 mmu problem

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!!

Parents
  • 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.

Reply
  • 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.

Children
More questions in this forum