linux-kernel - Re: [PATCH 09/33] ACPI / MPAM: Parse the MPAM table

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: <498b5814-28fb-4b5d-91a8-1aab02f3f5d6@nvidia.com>
Date: Wed, 12 Nov 2025 18:33:48 -0800
From: Fenghua Yu <fenghuay@...dia.com>
To: Ben Horgan <ben.horgan@....com>, james.morse@....com
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
 baolin.wang@...ux.alibaba.com, bobo.shaobowang@...wei.com,
 carl@...amperecomputing.com, catalin.marinas@....com, dakr@...nel.org,
 dave.martin@....com, david@...hat.com, dfustini@...libre.com,
 gregkh@...uxfoundation.org, gshan@...hat.com, guohanjun@...wei.com,
 jeremy.linton@....com, jonathan.cameron@...wei.com, kobak@...dia.com,
 lcherian@...vell.com, lenb@...nel.org, linux-acpi@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 lpieralisi@...nel.org, peternewman@...gle.com, quic_jiles@...cinc.com,
 rafael@...nel.org, robh@...nel.org, rohit.mathew@....com,
 scott@...amperecomputing.com, sdonthineni@...dia.com, sudeep.holla@....com,
 tan.shaopeng@...itsu.com, will@...nel.org, xhao@...ux.alibaba.com,
 Shaopeng Tan <tan.shaopeng@...fujitsu.com>
Subject: Re: [PATCH 09/33] ACPI / MPAM: Parse the MPAM table

Hi, Ben and James,

On 11/7/25 04:34, Ben Horgan wrote:
> From: James Morse <james.morse@....com>

[SNIP]

> +static int acpi_mpam_parse_resource(struct mpam_msc *msc,
> +				    struct acpi_mpam_resource_node *res)
> +{
> +	int level, nid;
> +	u32 cache_id;
> +
> +	switch (res->locator_type) {
> +	case ACPI_MPAM_LOCATION_TYPE_PROCESSOR_CACHE:
> +		cache_id = res->locator.cache_locator.cache_reference;
> +		level = find_acpi_cache_level_from_id(cache_id);
> +		if (level <= 0) {
> +			pr_err_once("Bad level (%d) for cache with id %u\n", level, cache_id);
> +			return -EINVAL;
> +		}
> +		return mpam_ris_create(msc, res->ris_index, MPAM_CLASS_CACHE,
> +				       level, cache_id);
> +	case ACPI_MPAM_LOCATION_TYPE_MEMORY:
> +		nid = pxm_to_node(res->locator.memory_locator.proximity_domain);
> +		if (nid == NUMA_NO_NODE) {
> +			pr_debug("Bad proxmity domain %lld, using node 0 instead\n",
> +				 res->locator.memory_locator.proximity_domain);
> +			nid = 0;
> +		}
> +		return mpam_ris_create(msc, res->ris_index, MPAM_CLASS_MEMORY,
> +				       255, nid);

nit.

Seems "255" is an ad-hoc value which won't be used for memory type?
The "class_id" in mpam_ris_create() is confused: it may be level for 
cache or it may be 255 for memory.

To be clearer, maybe it's better to define and enum for class_id? 
Something like:
enum mpam_class_id {
	CLASS_ID_LEVEL_1 = 1,
	CLASS_ID_LEVEL_2,
	CLASS_ID_LEVEL_3,
	CLASS_ID_NOT_USED = 255  <--- for memory type
};

Thanks.

-Fenghua