linux-kernel - Re: [PATCH 0/3] memory,acpi: resize memory blocks based on CFMW alignment

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 for Android: free password hash cracker in your pocket

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

Message-ID: <670543eae94d9_125a7294bd@iweiny-mobl.notmuch>
Date: Tue, 8 Oct 2024 09:38:35 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Gregory Price <gourry@...rry.net>, <linux-cxl@...r.kernel.org>,
	<x86@...nel.org>, <linux-mm@...ck.org>, <linux-acpi@...r.kernel.org>
CC: <linux-kernel@...r.kernel.org>, <dave.hansen@...ux.intel.com>,
	<luto@...nel.org>, <peterz@...radead.org>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>, <david@...hat.com>,
	<osalvador@...e.de>, <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
	<akpm@...ux-foundation.org>, <dan.j.williams@...el.com>,
	<Jonathan.Cameron@...wei.com>, <alison.schofield@...el.com>,
	<rrichter@....com>, <terry.bowman@....com>, <lenb@...nel.org>,
	<dave.jiang@...el.com>, <ira.weiny@...el.com>
Subject: Re: [PATCH 0/3] memory,acpi: resize memory blocks based on CFMW
 alignment

Gregory Price wrote:
> When physical address capacity is not aligned to the size of a memory
> block managed size, the misaligned portion is not mapped - creating
> an effective loss of capacity.
> 
> This appears to be a calculated decision based on the fact that most
> regions would generally be aligned, and the loss of capacity would be
> relatively limited. With CXL devices, this is no longer the case.
> 
> CXL exposes its memory for management through the ACPI CEDT (CXL Early
> Detection Table) in a field called the CXL Fixed Memory Window.  Per
> the CXL specification, this memory must be aligned to at least 256MB.
> 
> On X86, memory block capacity increases based on the overall capacity
> of the machine - eventually reaching a maximum of 2GB per memory block.
> When a CFMW aligns on 256MB, this causes a loss of at least 2GB of
> capacity, and in some cases more.
> 
> It is also possible for multiple CFMW to be exposed for a single device.
> This can happen if a reserved region intersects with the target memory
> location of the memory device. This happens on AMD x86 platforms. 

I'm not clear why you mention reserved regions here.  IIUC CFMW's can
overlap to describe different attributes which may be utilized based on
the devices which are mapped within them.  For this reason, all CFMW's
must be scanned to find the lowest common denominator even if the HPA
range has already been evaluated.

Is that what you are trying to say?

> 
> This patch set detects the alignments of all CFMW in the ACPI CEDT,
> and changes the memory block size downward to meet the largest common
> denomenator of the supported memory regions.
> 
> To do this, we needed 3 changes:
>     1) extern memory block management functions for the acpi driver
>     2) modify x86 to update its cached block size value
>     3) add code in acpi/numa/srat.c to do the alignment check
> 
> Presently this only affects x86, since this is the only architecture
> that implements set_memory_block_size_order.
> 
> Presently this appears to only affect x86, and we only mitigated there
> since it is the only arch to implement set_memory_block_size_order.

NIT : duplicate statement

Ira