linux-kernel - [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

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-next>] [day] [month] [year] [list]

Message-Id: <20180524201711.437084301@stormcage.americas.sgi.com>
Date:   Thu, 24 May 2018 15:17:11 -0500
From:   <mike.travis@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Dimitri Sivanich <dimitri.sivanich@....com>,
        Russ Anderson <russ.anderson@....com>,
        Andrew Banman <andrew.banman@....com>, jgross@...e.com,
        dan.j.williams@...el.com, mhocko@...e.com,
        kirill.shutemov@...ux.intel.com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

Update support for the UV kernel to accommodate Intel BIOS changes in
NVDIMM alignment, which caused UV BIOS to align the memory boundaries
on different blocks than the previous UV standard of 2GB.

Background: Since 2009 the UV arch dependent support has used 2GB as the
memory block size mainly to reduce the number of physical memory blocks
when a 16TB memory capable machine was introduced.  This significantly
reduced the time to initialize memory during system startup, and
has worked fine until Intel added PMEM NVDIMM's to the architecture.
This has caused the alignment boundary to be reduced to whatever is
needed to accommodate these new devices.

There are no other changes suggested by this patch set.  Basically the
previous strict boundary of 2GB has been relaxed to allow the arch
dependent code to adjust this memory block size depending on the
system requirements of the running environment.

* Patch 1
  Add a function for any arch dependent call to "adjust" this fixed
  memory block size.

* Patch 2
  Add a function to check what the minimum memory block size that can
  be used to accommodate where BIOS has set the boundaries for all of
  memory placement within node ranges.

* Patch 3
  Add a UV specific kernel arg to adjust for other memory block size
  adjustments that may be required with future new DIMM restrictions.
  Note that it can be raised (to 64GB) as well as lowered.  This should
  allow potential testing when the number of physical address bits are
  raised from the current 46 bit limit to 52 bits.

Note that an option I did consider was to make Patch 3 a more generic
function for all arches to use (IOW, with or without CONFIG_X86_UV set).
Opinions welcome about this.

--