linux-kernel - [PATCH 00/21] X86_64, UV: Update kernel for SGI UV4 support

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: <20160428231031.265120287@asylum.americas.sgi.com>
Date:	Thu, 28 Apr 2016 18:10:31 -0500
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Len Brown <len.brown@...el.com>,
	Dimitri Sivanich <sivanich@....com>
Cc:	Russ Anderson <rja@....com>, John Estabrook <estabrook@....com>,
	Andrew Banman <abanman@....com>,
	Nathan Zimmer <nzimmer@....com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 00/21] X86_64, UV: Update kernel for SGI UV4 support

This patch set primarily updates the Linux kernel to support the next
generation SGI Ultraviolet system, UV4.  This architecture change is a
larger incremental change than previous UV updates because of a major
change to the addressing scheme.  Previous UV architectures used a fixed
address width per node which was entirely appropriate, since the size
of RAM memory usually did not deviate very much between nodes.

Now on UV4 non-volatile memories can be added to any or all of the nodes.
The available sizes can be both smaller and much larger than that of
volatile memory on the same node.

To accommodate this configuration change, the architecture was updated
to support a varying per node memory width (or total per node memory).
And since this removed a key conversion factor known as "M" (the number
of address space bits per node), the kernel also had to change to support
the new address conversion functions.

Other changes in addition to this basic overhaul of the internal logic
include support for the increasing number of cores and thus CPU threads
per node.  Another inevitable architecture change will be the increase
of the system addressing space supported in future processors, upward
from the current 46 bits.

One other aspect, because these are somewhat extensive changes to the
UV kernel support system, we've also done extensive testing on current
UV architectures to insure that these changes do not break existing
functionality.  Since we do not have actual UV4 hardware yet, the
UV4 simulator has been used to test and debug UV4 specific changes.

Specific changes that support the updates are:

* Add support for UV4 specific hardware changes.  This was done in a
  way to maintain source code compatibility with supported external
  modules, for distros with kernel releases prior to the UV4 changes.

* Add new UV4 MMR definitions from automated verilog to MMR defines
  scripts.  Add control info to select UV4 in "UV common" functions.

* Migrate from using per cpu information structures to consolidating
  information common to nodes (move per cpu UVHUB info to per node info).

* Migrate more information look up from lists allocated on node 0 to
  structures allocated on the local node (move per blade info to per
  node info).

* Use more "soft" information that is collected by UV BIOS to control
  conversion routines instead of relying on information in MMR fields
  (gather more info from the EFI UVsystab system table.)

* Add high speed physical address to node/pnode/NASID conversion look ups.

* Add "soft" support for undefined MMR access to aid debugging the UV
  common functions.

* Remove support for UV1 going forward.  Remove obsolete GRU support from
  the GRU/XP drivers. Fix an ongoing problem determining the correct
  physical placement of nodes containing either no cpus or no memory
  ("headless/memoryless nodes").

--