Making MAX_PHYS_ADDRESS_BITS configurable

Making MAX_PHYS_ADDRESS_BITS configurable

[John Paul Adrian Glaubitz]

Hello!

A lot of JITs are using tagged pointers for performance reasons which
means that the pointer bits beyond the 47th or 48th should be kept
untouched by the kernel.

On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that
a lot of JITs crash on a sparc64 userspace [1].

Since other architectures like x86_64 and arm64 are catching up with their
address space extension with x86_64 bumping it to 56 and arm64 to 52 bits,
I assume this problem will hit these architectures in the future as well.

On the other hand, arm64 currently allows the virtual address size to be
configurable, currently defaulting to 48 bits [2, 3]. I was therefore
wondering whether we could make MAX_PHYS_ADDRESS_BITS [4] configurable
as well to be able to support these JITs on Debian/sparc64 for the foreseeable
future by limiting the virtual address space to 47 or 48 bits.

Thanks,
Adrian

> [1] https://bugreports.qt.io/browse/QTBUG-56264
> [2] https://patchwork.kernel.org/patch/10130743/
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/sparsemem.h?id˜2aa7c5f0861bf56b2412ca341a13f44c238ba4
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/sparc/include/asm/page_64.h#n140

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[John Paul Adrian Glaubitz]

On 5/24/19 12:24 PM, John Paul Adrian Glaubitz wrote:
> On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that
> a lot of JITs crash on a sparc64 userspace [1].

Correction, it shouldn't be MAX_PHYS_ADDRESS_BITS but sparc64_va_hole_top as
defined in mm/init_64.c.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[David Miller]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Fri, 24 May 2019 12:24:53 +0200

> On the other hand, arm64 currently allows the virtual address size
> to be configurable, currently defaulting to 48 bits [2, 3]. I was
> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
> configurable as well to be able to support these JITs on
> Debian/sparc64 for the foreseeable future by limiting the virtual
> address space to 47 or 48 bits.

You can't just do this.

It is possible that all physical memory is mapped to the top of the
mappable physical address range, therefore we really need to use the
full maximum setting supported by the CPU.

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[John Paul Adrian Glaubitz]

On 5/24/19 6:20 PM, David Miller wrote:
>> On the other hand, arm64 currently allows the virtual address size
>> to be configurable, currently defaulting to 48 bits [2, 3]. I was
>> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
>> configurable as well to be able to support these JITs on
>> Debian/sparc64 for the foreseeable future by limiting the virtual
>> address space to 47 or 48 bits.
> 
> You can't just do this.
> 
> It is possible that all physical memory is mapped to the top of the
> mappable physical address range, therefore we really need to use the
> full maximum setting supported by the CPU.

Yes, my initial mail was incorrect. What I actually meant was reducing
the size of the va_hole in userspace so that the top-most address that
mmap() would return is not beyond 2^47.

Would it be possible to add such a workaround until the JITs have fixed
their broken code?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Making MAX_PHYS_ADDRESS_BITS configurable

[David Miller]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Fri, 24 May 2019 20:51:33 +0200

> On 5/24/19 6:20 PM, David Miller wrote:
>>> On the other hand, arm64 currently allows the virtual address size
>>> to be configurable, currently defaulting to 48 bits [2, 3]. I was
>>> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
>>> configurable as well to be able to support these JITs on
>>> Debian/sparc64 for the foreseeable future by limiting the virtual
>>> address space to 47 or 48 bits.
>> 
>> You can't just do this.
>> 
>> It is possible that all physical memory is mapped to the top of the
>> mappable physical address range, therefore we really need to use the
>> full maximum setting supported by the CPU.
> 
> Yes, my initial mail was incorrect. What I actually meant was reducing
> the size of the va_hole in userspace so that the top-most address that
> mmap() would return is not beyond 2^47.
> 
> Would it be possible to add such a workaround until the JITs have fixed
> their broken code?

I suppose that's doable, sure.