Hi, Arnd, On Fri, Aug 20, 2021 at 3:55 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Fri, Aug 20, 2021 at 6:00 AM Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > On Wed, Aug 18, 2021 at 5:38 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > How common are Loongarch64 CPUs that limit the virtual address space > > > > > to 40 bits instead of the full 48 bits? What is the purpose of limiting the > > > > > CPU this way? > > > > We have some low-end 64bits CPU whose VA is 40bits, this can reduce > > > > the internal address bus width, so save some hardware cost and > > > > complexity. > > > > > > Ok. So I could understand making CONFIG_VA_BITS_40 hardcode the > > > VA size at compile time, but if you always support the fallback to any > > > size at runtime, just allow using the high addresses. > > Define a larger VA_BITS and fallback to a smaller one (TASKSIZE64) if > > hardware doesn't support it? If so, there will be a problem: we should > > define a 4-level page table, but the fallback only needs a 2-level or > > 3-level page table. > > The number of levels is usually hardcoded based on the configuration, > though I think at least x86 and s390 have code to do this dynamically, > either depending on the CPU capability, or the largest address used > in a task. > > The easiest example to replicate would be arch/arm64, which lets you > pick the page size first, and then offers different VA_BITS options that > depend on this page size. > > Another method is to have a single 'choice' statement in Kconfig that > simply enumerates all the sensible options, such as > > 4K-3level (39 bits) > 4K-4level (48 bits) > 4K-5level (56 bits) > 16K-2level (36 bits) > 16K-3level (47 bits) > 64K-2level (42 bits) > 64K-3level (55 bits) > > You might prefer to offer the order-1 PGD versions of these to get > to 40/48/56 bits instead of 39/47/55, or just offer both alternatives. Use combination option is a good idea, thanks. Huacai > > Arnd
