Making MAX_PHYS_ADDRESS_BITS configurable

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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=982aa7c5f0861bf56b2412ca341a13f44c238ba4
> [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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Making MAX_PHYS_ADDRESS_BITS configurable

Gregor Riepl-2
>> 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.

That sounds like a good compromise, considering that hardware making use of
such a huge address space is currently not widely available.

Is there anything in the SPARC spec that mandates 52 virtual address bits? Why
was this value chosen in the first place?

Reply | Threaded
Open this post in threaded view
|

Re: Making MAX_PHYS_ADDRESS_BITS configurable

David Miller-13
In reply to this post by John Paul Adrian Glaubitz
From: John Paul Adrian Glaubitz <[hidden email]>
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.

Reply | Threaded
Open this post in threaded view
|

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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Making MAX_PHYS_ADDRESS_BITS configurable

David Miller-13
From: John Paul Adrian Glaubitz <[hidden email]>
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.