From: Arnd Bergmann <firstname.lastname@example.org> To: Stefan Agner <email@example.com> Cc: Mike Rapoport <firstname.lastname@example.org>, Minchan Kim <email@example.com>, firstname.lastname@example.org, Sergey Senozhatsky <email@example.com>, Andrew Morton <firstname.lastname@example.org>, email@example.com, gregkh <firstname.lastname@example.org>, Arnd Bergmann <email@example.com>, Linux-MM <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Russell King - ARM Linux <email@example.com> Subject: Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS Date: Tue, 10 Nov 2020 16:19:30 +0100 [thread overview] Message-ID: <CAK8P3a1JEthD7j0qM05Vm94OpbTFqi_7+pe7LKX7eaANES7ifirstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Tue, Nov 10, 2020 at 1:24 PM Stefan Agner <firstname.lastname@example.org> wrote: > On 2020-11-10 12:21, Arnd Bergmann wrote: > > Good idea. I wonder what other architectures need the same though. > > >> That's what x86 does: > >> > >> $ git grep -w MAX_POSSIBLE_PHYSMEM_BITS arch/ > >> arch/x86/include/asm/pgtable-3level_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS 36 > > > > Doesn't x86 also support a 40-bit addressing mode? I suppose > > those machines that actually used it are long gone. > > > >> arch/x86/include/asm/pgtable_64_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS 52 > >> > >> It seems that actual numbers would be 36 for !LPAE and 40 for LPAE, but > >> I'm not sure about that. > > > > Close enough, yes. > > > > The 36-bit addressing is on !LPAE is only used for early static mappings, > > so I think we can pretend it's always 32-bit. I checked the ARMv8 reference, > > and it says that ARMv8-Aarch32 actually supports 40 bit physical addressing > > both with non-LPAE superpages (short descriptor format) and LPAE (long > > descriptor format), but Linux only does 36-bit addressing on superpages > > as specified for ARMv6/ARMv7 short descriptors. > > Oh so, more than 4GB of memory can be supported by !LPAE systems via > superpages? Wasn't aware of that. Not really, we only really use it for MMIO mappings, and only on the Xscale3 CPU. Support for this was originally added for IXP23xx, and the same core is present in IOP13xx and PXA3xx, but only the last one of these is still supported in mainline, and I don't know if it actually has anything outside of the 32-bit address space (arch/arm/mach-pxa/include/mach/addr-map.h suggests it does not) Russell might remember more details here, and if there is a reason to keep IO_36 support working after we removed IXP23xx back in 2012 and never enabled it for ARMv6 or v7. I suppose removing it would only change a few lines in asm/domain.h, as we'd still want to keep supersection support regardless. > Since only ARM_LPAE selects CONFIG_PHYS_ADDR_T_64BIT it really is safe > to assume 32 bits for non-LPAE systems. > > I guess that would mean adding a #define MAX_POSSIBLE_PHYSMEM_BITS 32 to > arch/arm/include/asm/pgtable-2level.h and a MAX_POSSIBLE_PHYSMEM_BITS 40 > in arch/arm/include/asm/pgtable-3level.h. Seems straight forward and > would solve the problem I had. I can prepare a patch for ARM, not sure > about the other architectures... I think I can help with that once we have agreed on a patch for ARM. Arnd
next prev parent reply other threads:[~2020-11-10 15:19 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-07 15:22 Stefan Agner 2020-11-08 0:56 ` Andrew Morton 2020-11-08 1:16 ` Stefan Agner 2020-11-08 4:54 ` Florian Fainelli 2020-11-09 17:04 ` Minchan Kim 2020-11-08 6:46 ` Mike Rapoport 2020-11-10 9:29 ` Stefan Agner 2020-11-10 9:58 ` Mike Rapoport 2020-11-10 11:21 ` Arnd Bergmann 2020-11-10 12:22 ` Stefan Agner 2020-11-10 15:19 ` Arnd Bergmann [this message] 2020-11-10 16:21 ` Mike Rapoport 2020-11-10 23:36 ` Minchan Kim 2020-11-11 6:52 ` Mike Rapoport 2020-11-12 19:49 ` Minchan Kim 2020-11-11 9:33 ` Arnd Bergmann 2020-11-11 10:26 ` Mike Rapoport 2020-11-11 10:57 ` Arnd Bergmann 2020-11-11 11:04 ` Mike Rapoport 2020-11-11 13:39 ` Thomas Bogendoerfer 2020-11-11 14:33 ` Arnd Bergmann 2020-11-12 19:50 ` Minchan Kim 2020-11-12 23:46 ` Florian Fainelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK8P3a1JEthD7j0qM05Vm94OpbTFqi_7+pe7LKX7eaANES7iemail@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).