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

[Huacai Chen <chenhuacai@gmail.com>]

Hi, Arnd,

On Fri, Aug 13, 2021 at 3:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Aug 13, 2021 at 5:30 AM Huacai Chen <chenhuacai@gmail.com> wrote:
> > On Thu, Aug 12, 2021 at 8:46 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > > +#ifdef CONFIG_VA_BITS_40
> > > > > > +#define TASK_SIZE64     (0x1UL << ((cpu_vabits > 40)?40:cpu_vabits))
> > > > > > +#endif
> > > > > > +#ifdef CONFIG_VA_BITS_48
> > > > > > +#define TASK_SIZE64     (0x1UL << ((cpu_vabits > 48)?48:cpu_vabits))
> > > > > > +#endif
> > > > >
> > > > > Why would the CPU have fewer VA bits than the page table layout allows?
> > > > PAGESIZE is configurable, so the range a PGD can cover is various, and
> > > > VA40/VA48 is not exactly 40bit/48bit, but 40bit/48bit in maximum.
> > >
> > > Do you mean the page size is not a compile-time constant in this case?
> > >
> > > What are the combinations you can support? Is this a per-task setting
> > > or detected at boot time?
> > Page size is a compile-time configuration. Maybe you or maybe me get
> > lost here.:)
> > What I want to do here:
> > 1, I want to provide VA40 and VA48 for user-space.
> > 2, CPU's VA bits may be 32, 36, 40, 48 or other values (so we need
> > (0x1UL << ((cpu_vabits > 40)?40:cpu_vabits)) or something similar).
> > 3, The range a PGD can cover depends on PAGE SIZE (so it cannot
> > exactly equals to 40/48).
>
> I still don't see what is special about 40 and 48. From what I can tell,
> you have two constraints: the maximum address space size for
> the kernel configuration based on the page size and number of
> page table levels, and the capabilities of the CPU as described
> in the CPUCFG1 register.
>
> What is the point of introducing an arbitrary third compile-time
> limit here rather than calculating it from the page page size?
So your problem is why we should provide two configurations VA40 and
VA48? This is derived from MIPS of course, but I found that RISC-V and
ARM64 also provide VA BITS configuration.

Huacai
>
> > > I would suggest you don't plan to ever add LPX32 in this case, it
> > > has never really caught on for any of the architectures that support
> > > it other than mips, and even there I don't think it is used much
> > > any more.
> > >
> > > It's certainly easier to have fewer ABI options.
> > LPX32 is just a placeholder now, and maybe a placeholder for ever. :)
>
> Ok, fair enough.
>
>
>        Arnd