linux-kernel - Re: [PATCH 1/1] cxl/acpi.c: Add buggy BIOS hint for CXL ACPI lookup failure

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: Sun, 28 Apr 2024 22:57:13 -0700
From: PJ Waskiewicz <ppwaskie@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Dan Williams <dan.j.williams@...el.com>, linux-cxl@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] cxl/acpi.c: Add buggy BIOS hint for CXL ACPI lookup
 failure

On Tue, 2024-04-09 at 08:22 -0500, Bjorn Helgaas wrote:
> On Sun, Apr 07, 2024 at 02:05:26PM -0700, ppwaskie@...nel.org wrote:
> > From: PJ Waskiewicz <ppwaskie@...nel.org>
> > 
> > Currently, Type 3 CXL devices (CXL.mem) can train using host CXL
> > drivers on Emerald Rapids systems.  However, on some production
> > systems from some vendors, a buggy BIOS exists that improperly
> > populates the ACPI => PCI mappings.
> 
> Can you be more specific about what this ACPI => PCI mapping is?
> If you already know what the problem is, I'm sure this is obvious,
> but
> otherwise it's not.

Apologies for the delay in response.  Things got a bit busy with travel
and whatnot...

On one of these particular hosts, in /sys/bus/acpi/devices/ACPI0016:00,
for example, the UID would be something like CX01.  It isn't an u64 at
all, and there's no atoi() or other conversions that would match what
the UID should be.

In my case, /sys/bus/acpi/devices/ACPI0016:02/ is my CXL device in
question. The UID that is presented from enumeration was CX02. 
However, if I scour the CEDT manually, the UID of my particular CXL
device is really UID 49.

So, if I went from the PCI/CXL device side, and called something along
the lines of to_cxl_host_bridge() and tried to go from the pci_dev to
the acpi_handle, I'd get CX02 back.  Then trying to use that to call
acpi_table_parse_cedt() would fail.

The BIOS fix from the vendor corrected the UID enumeration on the ACPI
side.  This allowed things to properly line up when traversing through
the kernel APIs and parsing the ACPI tables.

Let me know if this helps clarify!  If not, I can try and get more
detailed info.

-PJ