netdev - Re: [PATCH v9 13/27] cxl: prepare memdev creation for type2

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: <679029b29571d_20fa294be@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 21 Jan 2025 15:11:46 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alejandro Lucero Palau <alucerop@....com>, Dan Williams
	<dan.j.williams@...el.com>, <alejandro.lucero-palau@....com>,
	<linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>
Subject: Re: [PATCH v9 13/27] cxl: prepare memdev creation for type2

Alejandro Lucero Palau wrote:
[..]
> > If an accelerator has a CDAT it will get qos_class information for free.
> > If it does not have a CDAT then I wonder how it is telling the BIOS the
> > memory type for its CXL.mem?
> 
> AFAIK, this is not mandatory, and the BIOS will look at CXL DVSEC for 
> finding out. So no perf data is mandatory.

Right.

> FWIW, our device will export a CDAT via PCI option rom since we have to 
> avoid the BIOS doing things we do not want to like testing the memory as 
> some BIOS seem to do in some debug/test mode, and to advertise this flag 
> we discussed in v1/RFC for the kernel doing nothing with that memory 
> when found in the HMAT table.

As long as devices that put standard things in standard places get
standard Linux enabling, I am satisfied.

As for the comment about HMAT, I am not sure what that is referring?

The kernel should not need any other consideration for CXL accelerators.
Either accelerator memory is properly marked Reserved in the EFI map, or
it is not. It is a BIOS bug if it maps accelerator memory as EFI
Conventional Memory (with or without the EFI_MEMORY_SP) and per the EFI
spec the kernel has no responsibility to fix that up.