Query regading the Translation table about lk HOT 3 OPEN

Hi! Which architecture are you asking about in this case? I'm guessing this is riscv64, since from what I can remember that's the only one that generally defaults to Sv39.

In the case of a Sv48 arch, the code has the logic to deal with it, it just has to be compile time set to a Sv48. See https://github.com/littlekernel/lk/blob/master/arch/riscv/rules.mk#L50

from lk.

Hi @travisg thanks for the info.
Sorry I forgot to mention the architecture.
Hi @travisg.
can you help me with another query regarding arm64.
In arm64, does it supports VA>39 bits?
Also as you can see here:
[https://github.com/littlekernel/lk/blob/master/arch/arm64/rules.mk#L62C1-L62C20]
I was just wondering the USER_ASPACE_BASE will vary according to the user, right? If the user changes it, Will the USER_ASPACE_SIZE will still be the same? I understand the USER APSACE SIZE can go till max 0XFFFFFFFFFFFF.
From what I could understand from code the sum of USER_ASPACE_BASE + USER_ASPACE_SIZE should be 0xFFFFFF000000. is this the correct understanding or I'm missing something?

from lk.

ARM64 indeed supports more than 39 bits. In the default configuration each half of the total address space is 48 bits long, so what those constants are marking is:
user aspace 0x100.0000 - 0x0000.ffff.ffff.ffff
kernel aspace 0xffff.0000.0000.0000 .... 0xffff.ffff.ffff.ffff

The reason for user aspace not being based at 0 is to keep 0 unmapped, so that null pointers are trapped. Actual hardware supports down to 0.

Of course, the full 64bit address space is not supported on ARM64 (or most architectures for that matter), so there's a gap of unusable hardware space between 0x0000.ffff.ffff.ffff - 0xffff.0000.0000.0000.

from lk.