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]
Message-ID: <ZqlF0hn6Jh4Ybl-p@PC2K9PVX.TheFacebook.com>
Date: Tue, 30 Jul 2024 15:58:10 -0400
From: Gregory Price <gourry@...rry.net>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org, dave.jiang@...el.com,
	Jonathan.Cameron@...wei.com, horenchuang@...edance.com,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	dan.j.williams@...el.com, lenb@...nel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH] acpi/hmat,mm/memtier: always register hmat adist
 calculation callback

On Wed, Jul 31, 2024 at 09:22:32AM +0800, Huang, Ying wrote:
> Gregory Price <gourry@...rry.net> writes:
> 
> > This presumes driver configured devices, which is not always the case.
> >
> > kmem.c will set MEMTIER_DEFAULT_DAX_ADISTANCE
> >
> > but if BIOS/EFI has set up the node instead, you get the default of
> > MEMTIER_ADISTANCE_DRAM if HMAT is not present or otherwise not sane.
> 
> "efi_fake_mem=" kernel parameter can be used to add "EFI_MEMORY_SP" flag
> to the memory range, so that kmem.c can manage it.
> 

In this case, the system is configured explicitly so that kmem does not
manage it. In fact, some systems still cannot be managed with
EFI_MEMORY_SP due to hpa!=spa issues that the driver cannot manage.

> > Not everyone is going to have the ability to get a platform vendor to
> > fix a BIOS bug, and I've seen this in production.
> 
> So, some vendor build a machine with broken/missing HMAT/CDAT and wants
> users to use CXL memory devices in it?  Have the vendor tested whether
> CXL memory devices work?
>

As I mentioned, the broken aspect is being fixed, however there are
existing production hardware which do not have HMAT entries.

> > But the first step here would be creating two modes.  HMAT-is-sane and
> > CPU/Non-CPU seems reasonable to me but open to opinions.
> 
> IMHO, we should reduce user configurable knobs unless we can prove it
> is really necessary.
>

That's fair and valid.

But I think a feature that worked in 5.x should work in 6.x, and right
now the change in node placement breaks hardware that worked with 5.x
which happened to have broken or missing HMAT.

~Gregory

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ