Thread (14 messages) 14 messages, 2 authors, 2021-08-21

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

From: Huacai Chen <hidden>
Date: 2021-08-13 08:14:39

Possibly related (same subject, not in this thread)

Hi, Arnd,

On Fri, Aug 13, 2021 at 3:05 PM Arnd Bergmann [off-list ref] wrote:
On Fri, Aug 13, 2021 at 5:30 AM Huacai Chen [off-list ref] wrote:
quoted
On Thu, Aug 12, 2021 at 8:46 PM Arnd Bergmann [off-list ref] wrote:
quoted
quoted
quoted
quoted
+#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
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help