Re: [PATCH 04/19] LoongArch: Add common headers

[Arnd Bergmann <arnd@arndb.de>]

On Fri, Aug 20, 2021 at 6:00 AM Huacai Chen <chenhuacai@gmail.com> wrote:
> On Wed, Aug 18, 2021 at 5:38 PM Arnd Bergmann <arnd@arndb.de> 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.

       Arnd