Messages in this thread | | | Date | Thu, 09 Dec 2021 11:21:53 +0000 | From | Paul Cercueil <> | Subject | Re: config CPU_SUPPORTS_HUGEPAGES refers to the non-existing symbol ARCH_PHYS_ADDR_T_64BIT |
| |
Hi Lukas,
Le mer., déc. 8 2021 at 12:43:00 +0100, Lukas Bulwahn <lukas.bulwahn@gmail.com> a écrit : > Dear Daniel, dear Paul, dear Thomas, > > In commit d4a451d5fc84 ("arch: remove the ARCH_PHYS_ADDR_T_64BIT > config symbol") from April 2018, the config ARCH_PHYS_ADDR_T_64BIT was > removed and all instances of that config were refactored > appropriately. Since then, it is recommended to use the config > PHYS_ADDR_T_64BIT instead. > > Then in June 2019, commit 171543e75272 ("MIPS: Disallow > CPU_SUPPORTS_HUGEPAGES for XPA,EVA") introduces the expression > "!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))" for config > CPU_SUPPORTS_HUGEPAGES, which refers to the non-existing symbol > ARCH_PHYS_ADDR_T_64BIT. > > In this expression, the symbol ARCH_PHYS_ADDR_T_64BIT always evaluates > to false. So, the expression is effectively "!(32BIT && EVA)" right > now. > > Now, it is a bit unclear what is intended here, especially since it > was not noticed to be wrong for the last two years: > > - The commit is buggy, but nobody noticed it so far. It was intended > to refer to PHYS_ADDR_T_64BIT. We need to provide a fix that changes > the semantics by referring to the intended Kconfig symbol.
It should be PHYS_ADDR_T_64BIT, yes.
> - The commit is just a bit unclean and that is why nobody noticed. The > reference to ARCH_PHYS_ADDR_T_64BIT can be dropped. We can provide a > clean-up patch that preserves the current semantics.
AFAIK hugepages still don't work as-is on 32-bit as we are running out of available bits in PTEs. I do have hugepages enabled on a kernel build, but I have to manually disable ARCH_HAS_PTE_SPECIAL and CPU_HAS_RIXI to free up space. This is annoying but not something that can be fixed easily.
-Paul
> Once the situation for that commit and its intention is clear, I am > happy to provide the suitable patch. > > Best regards, > > Lukas
| |