linux-kernel - Re: [PATCH 0/5] selftests/mm: Implement support for arm64 on va

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Mar 2023 11:59:14 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Chaitanya S Prakash <chaitanyas.prakash@....com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 0/5] selftests/mm: Implement support for arm64 on va

On Thu, Mar 23, 2023 at 02:14:36PM +0300, Kirill A. Shutemov wrote:
> On Thu, Mar 23, 2023 at 04:22:38PM +0530, Chaitanya S Prakash wrote:
> > The va_128TBswitch selftest is designed and implemented for PowerPC and
> > x86 architectures which support a 128TB switch, up to 256TB of virtual
> > address space and hugepage sizes of 16MB and 2MB respectively. Arm64
> > platforms on the other hand support a 256Tb switch, up to 4PB of virtual
> > address space and a default hugepage size of 512MB when 64k pagesize is
> > enabled.
> > 
> > These architectural differences require introducing support for arm64
> > platforms, after which a more generic naming convention is suggested.
> > The in code comments are amended to provide a more platform independent
> > explanation of the working of the code and nr_hugepages are configured
> > as required. Finally, the file running the testcase is modified in order
> > to prevent skipping of hugetlb testcases of va_high_addr_switch.
> > 
> > This series has been tested on 6.3.0-rc3 kernel, both on arm64 and x86
> > platforms.
> > 
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Aneesh Kumar K.V <aneesh.kumar@...ux.ibm.com>
> > Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> > Cc: Shuah Khan <shuah@...nel.org>
> > Cc: linux-mm@...ck.org
> > Cc: linux-kselftest@...r.kernel.org
> > Cc: linux-kernel@...r.kernel.org 
> > 
> > Chaitanya S Prakash (5):
> >   selftests/mm: Add support for arm64 platform on va switch
> >   selftests/mm: Rename va_128TBswitch to va_high_addr_switch
> >   selftests/mm: Add platform independent in code comments
> >   selftests/mm: Configure nr_hugepages for arm64
> >   selftests/mm: Run hugetlb testcases of va switch
> > 
> >  tools/testing/selftests/mm/Makefile           |  4 +-
> >  tools/testing/selftests/mm/run_vmtests.sh     | 12 +++++-
> >  ...va_128TBswitch.c => va_high_addr_switch.c} | 41 +++++++++++++++----
> >  ..._128TBswitch.sh => va_high_addr_switch.sh} |  6 ++-
> >  4 files changed, 49 insertions(+), 14 deletions(-)
> >  rename tools/testing/selftests/mm/{va_128TBswitch.c => va_high_addr_switch.c} (86%)
> >  rename tools/testing/selftests/mm/{va_128TBswitch.sh => va_high_addr_switch.sh} (89%)
> 
> The patchset looks sane to me, but I have question: why arm64 has switch
> on 256TB. The reason we have the switch is to keep system backward
> compatible.

It's the same reason, it's just that arm64 initially supported 48-bits / 256TB
of user addresses (0x0000000000000000..0x0000ffffffffffff), while x86_64
supported 47-bits / 128TB (0x0000000000000000..0x00007fffffffffff).

Note: arm64 has separate page tables for the user / kernel halves of the VA
space, which in practice means we get an extra bit of address range for each
half.

> Maybe it is better to make arm64 switch also on 128TB to make it
> compatible across architectures?

I don't think that's something that we can change; user addresses between 128TB
and 256TB have been the case for over a decade now, and avoiding that by
default could easily break something.

Thanks,
Mark.