From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49FA9449EB6 for ; Tue, 14 Jul 2026 15:19:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.21 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784042367; cv=fail; b=bOf4aFvs9yPMRCkJkNFC9jGMohRW8i5AgcP13HZyNs3u9drllJnT/cf/AN+L0cc1rkZlRhwDwTWQOi4b9j5lI1o01A9RZMfeRDrZPQaub2qSEyna8LFqJpdwUiXPfUNY+6cNpqPqRBlpxXndVVWJTTKBDPQh7aqcwcj40/tmCaQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784042367; c=relaxed/simple; bh=IpJxL8JCN2xscYryZJykf68pvwQGAVDG5Ov9m0iNeqk=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=qAWUWjlUELNjZDPdGiHPon/ZIySus8XbOI+zP3itpKnkvRMgAen952SDCuAxbw+pE0/LOWWoNiV4GZouNM+TzWuXjxyp/ufEc+bwYuQifEPLwE2RISVQMod+LHqBbzkbRwBfqMI5t4FbZ8rDFDF493wo0ZY1yF0EhbkAjpS0OwI= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ARXuCwT0; arc=fail smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ARXuCwT0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784042365; x=1815578365; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=IpJxL8JCN2xscYryZJykf68pvwQGAVDG5Ov9m0iNeqk=; b=ARXuCwT02zas6lJ72amLcHdwLrP+zLEc5aDTPUoAeF/sUewO74Bp+hby yHh/Ut8BYBsSHmSLfbB4eK1CuvBv6ipOYw0jea39siZAa9N52kmPTmua0 w9SLUaerLMiXMhTtrW6ewO/ugG/CmQqvDiF2U/BH/vSa/r8fZHFGjpvs6 AxIntAdBwAZnHBs0L4pFdS2EHOt6Cf/X2lRNUwKcgG/Q+AkHEz9B0x7K4 uiKTKcCuJSao5eav+pqB6cDH2vgxN3PWSkWdVP+9tCzGKNAFFDgfK+7y3 dcdRwXrbJSLhGipnav+JCScAYUN6UW5PCzr08n6kvtB/8BL8Nqyo9TayP A==; X-CSE-ConnectionGUID: ijj7S3YzSMy4YuE9B1mHsg== X-CSE-MsgGUID: 3EG42gh/SMiXHFPUIuDCfg== X-IronPort-AV: E=McAfee;i="6800,10657,11846"; a="84521696" X-IronPort-AV: E=Sophos;i="6.25,164,1779174000"; d="scan'208";a="84521696" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 08:19:25 -0700 X-CSE-ConnectionGUID: BywCQvJ0RPu7PopnfHnlaA== X-CSE-MsgGUID: Gvkbpq3vTyed9+tPPja/CQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,164,1779174000"; d="scan'208";a="255390400" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 08:19:25 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 14 Jul 2026 08:19:23 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43 via Frontend Transport; Tue, 14 Jul 2026 08:19:23 -0700 Received: from CO1PR03CU002.outbound.protection.outlook.com (52.101.46.33) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 14 Jul 2026 08:19:23 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wOKCCGFXVBBYGY/EzKY9QfvoDhe2zVrkX/I1ssRA9H2QCXVT4s5hKfpqtLS8UJmSLzJpoLet0kNmhC3b3ZY2YIqQztmO82WwaeK2k1iZzx2NBJXxCAiO0OXIkKVafJG7QSzQJZQL1dj5YRNnIYa1Kk/S687lxl+YWf3rdlto5LGgdWu+5Xfb1cOoKOk8WzjcC8ugWwjz6RHxFLUOPZ+Uh2K0E12UGVIyPjO/qnfFMeqd4mLTI69/PVXeAIed/Tp3nMMVYLxRHTcjEpz2Y5JFJqVSbqnewI5cobt/PvhnGqyaFj8+BMjCPjVgGMKX1g8tymaACAMdJP4oM3jM/OyLeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s7OUvhdRESx8873p0yJHPmFRsD2Xxgv7sDti3+U/U1w=; b=VHrYqcP/eQllYFBi6sv1rr8vZ62DqpvU9qCQcJssYqzcdIvN+qhv+C1Bxq3PFWxzU3dEHzUhE2x0rfZxLB5XqKH6Km+srejyU1gK8NJKsB7anR9xo25RvHAWdRL0fCaqkuz9ekvO+pnxU1Lf7YEikl0Siga0Q6OYpojY52eU5c5QQdZ/kcEWgeKMjriE82pbBJs1sFVKKhbRFspZNT8yVbChWKkPsp4A+pCMzD+JBl27qauL7yPyInPIW7pPVHGDcADCIImQw/ZYpwMh/NwcxmHHBQsIO3rcKPNeJmvLdYb/IEIlcO2+3PYKVuAjlCJat8W2CUMrL+EapH0doRghxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) by PH0PR11MB7471.namprd11.prod.outlook.com (2603:10b6:510:28a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.9; Tue, 14 Jul 2026 15:19:20 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%4]) with mapi id 15.21.0202.018; Tue, 14 Jul 2026 15:19:20 +0000 Message-ID: <113d3788-4388-4bf0-ad1f-d03232d770b6@intel.com> Date: Tue, 14 Jul 2026 23:19:09 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/10] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask for RMDD domains To: Reinette Chatre CC: , , , , , , , , , , , Hongyu Ning , References: <04bf985905dfaa759b919a11fd5d806b179fc0bb.1782866200.git.yu.c.chen@intel.com> <83182a45-e4e5-47df-88cd-79c0f6beaed1@intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <83182a45-e4e5-47df-88cd-79c0f6beaed1@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2P153CA0027.APCP153.PROD.OUTLOOK.COM (2603:1096:4:190::22) To DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6020:EE_|PH0PR11MB7471:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f74eb0b-a7c0-4d6d-ae70-08dee1bb46b5 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|7416014|22082099003|18002099003|11063799006|4143699003|56012099006|3023799007; X-Microsoft-Antispam-Message-Info: VqTT+BwwTo6d6u8OeAdBO2KMAB4OAwc/OVgQVA0NLkdyMmftb0B2gBFz206kAbxhrmvozoza6YZJTkvQAJ4wMkweAnhqky2OFWGmU4Z+yaP3YTuKQyaRUoUzNeoSEr7yl01XgC5pqjKaRN8TkIJT0B+m7bfACilzw0nYX61T9nzqMnV1ftdJ5qjixbyB54C0GpsfBP4VEZ23F6X61Cz1HoXfe+1YjDS/tx6U9pMkocervO4rzmS8km+D2L1vfaHqMvlg/YkUwJOzYsyAPRJdwaY/qWaFmn+1NCKRskIqpDswxw9zvH8OyPCh4sUNegoeJ27BalSX8h1qylrXZpFr9oCj1y1mC+h4nzrR7ezYzY2VHwc9zfR4lNKTjQpT/MtLnJ3UoTjs36Rvo6Sb9x30K5kdwbPh5QDEFUTp9xV1VXknO/nnV2Bb2J3WtFiG9mgpi6M1c5TFRpNj3LBot89ePhemdw3OaWoQvzZII9Px3g5I9ELBdH2bn6Irnz2IaOR5h5+bOj46YWzLfffekr7p9pUx98tJUc6vvcO59GQclew5NDLHzTJNTUtg43dZQLAaL6we9YrMkzQ3OVUnqNDXT6tKcUjvNJ7BnwLl8KxUEQXgBsSonmitivuCiVExxHIiea4zy8NatBuFrWvwfURk1F2wvMaPWfGiRF7oGveZBC4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB6020.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(7416014)(22082099003)(18002099003)(11063799006)(4143699003)(56012099006)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Kzg4QmFFUUFOZXhGLysxalpBeHY0R3VpOXNlRUU2emJqcVIrMSsxMW92MHo4?= =?utf-8?B?bDA1L2N1T3JIS0QyMlJmbXJiTkErNFRzSDVSOVo1ZUVHZkFyRm9MY05GQ1Ir?= =?utf-8?B?bDliUkk2cS9uaTNqU3dtc3ZKVDdNclJySWRlYjBaMWlkTmNjc2RRSzNtTmk5?= =?utf-8?B?MXo2Y1cwVzl1ZVVBRjczZmNTTTkvaTgySW9ZUjV2ZzhhUWJTenhZei9ORVlo?= =?utf-8?B?YnU3LzBqV09sRmtFekF3Y09SMXh0WUhncmUxeVdtUUU5aTJieEl6ZEdhdVdJ?= =?utf-8?B?UkhDTE5nTTFDbE1PZ1U5ZnR2OHVxdkc3cnpFaFFBck02c2NmOCt3dU9Zb3M1?= =?utf-8?B?dGNON2Z2Yk9CR3JTOC9GU0VSVGd2ajFqc2QvUEtNSjVoTVBhaDBHQWhFQkhL?= =?utf-8?B?SU1oL1pVcGJ5d05yYkYvL1Z3TU5wQ3VrTDZHWTJjUXZzVHl1VFBUK0xlQTdp?= =?utf-8?B?ZGp3b1NINkZ3YlpkOXkrTi8rb01WZEhDUlpBdVFNc1pKb2VmMFAwaDNtQisx?= =?utf-8?B?ald3TkJIRzNUK3BTelBtbk1DZGx0aVVhYXNWTFcxcnZaT3VqR0kvRWZQa21v?= =?utf-8?B?ZktGRTVHV2hCVjd2RGFNaVBNN2hjdWl5VnB2WE9Qc0RYdExBNHBzVUdobE93?= =?utf-8?B?Rk1XVFpadGNDOFhpVUVrclAySzlaV2tWeXI3d1N5bVFkR1g2OHBmV2MvZ1RK?= =?utf-8?B?Z3ZsQTRKWGFkV0pKMkpHQmFKb2Zjd3dUd2RVN1Y1V1VsMWpUV0VwUU1CMnB3?= =?utf-8?B?SUNkTlVvNWs1ek1WNk15WHdaYjV5aDB6TCtNNmpiMFByMENtcTN6bXhUSGZp?= =?utf-8?B?K1B0OEF4UXVjUnhPNjVEWlZvU3VXU01OcndKdlZJNytqVzYzR253MVY3cDBW?= =?utf-8?B?LzVQS0U5SmJNWmFSMnNZRzNwaVRTQ24wamI2ZlFNVS9EcGtxU3hlSkdwdW5p?= =?utf-8?B?K3dtd3k2dmJqRjNsajV5NDRvUUJia242Qk1WdjNzZDUxME1LSXFPSzRwUkc5?= =?utf-8?B?ek1qc0dpbVJTMk1nclJMVnFxRTBUNUpwWEhFRU1qcy9zTTZwTHFCUzhUY3cr?= =?utf-8?B?UVZwQ3ozaW5jYVVHMDBHdW1aVHhzQTlidVRiaHVHQm5XSk9id25sUVBIL2NR?= =?utf-8?B?SjYvR1RQaW5hMVFub0lKRWovVEYycVY1YlRUdTdTWUJ5L2JZSFhxSDlBZk1T?= =?utf-8?B?U2ljRHkxUTl5eHhzblppbGxZS2NERC82cGRRSE16OW9YTzRNdmk3WHlKVTVi?= =?utf-8?B?b2ZYTGdFRmhOK3czbFZ4NmU1L3VTcUkrY2lhRWFZMVU5Vmh5SG84UkV6ci9u?= =?utf-8?B?MHJ5Wm02QnNHb25LZW0zRmZyLzZUaXhxZE8ydThkVDNaTlZVL0hWN3VYUzBx?= =?utf-8?B?THdVUm9UMjA0b0FDS3RkUkxmZGc5ZlV1SHF5UjRUTW5Vb3dnQW0xWnRvcTJR?= =?utf-8?B?NzcvZEdqUUFtWll6amdUMDhjWW1vbHF0a0pLRUI0M3ZEUjRVMHhKQ3NOMC96?= =?utf-8?B?YTV3cTRIV1U3aTJYb3NiSXJZdmE1T2NaTG43SzBldG8ybHl5RjFGQVYvNm8v?= =?utf-8?B?YUxlVjY1RzczanhuTWFLdmkzZDlTcnRhT0V6V0tIYkFSQllJQUtQMzJTQ0dT?= =?utf-8?B?T0pwVFhJandsWnk2WHU0Rm9GRGRoN2QyV3h5d1hHaWRaMEg5VkxxK05PY1Vi?= =?utf-8?B?TnBhSXhxSm5VUGFhWjNCenBLVXJST0hxUUZXdXpTdS8rZUxCemJZMy9oeDhM?= =?utf-8?B?cGM4bXh6LzR2bnh1SllrZnZUTExjMkVJNk4ycXgySEdseUpjTGpHU20vQ3or?= =?utf-8?B?Yzc4NTVNWXNUbHlhQTQ5Y3hGOXBIRW5kbG1UZEVJNkpiNmxwNEdWNUVCRHNw?= =?utf-8?B?TkV3eDJVRDhEZXRQSW9NdVJEQlU3TUZxamNuY1NSUnZZM1pMS25NY1Z3akR4?= =?utf-8?B?T2pJZWpzY1FWQ1M0Mi9WZkt2Y2QwcVRZL2QrbW9walVrdFh6bFNmbzVTdzhv?= =?utf-8?B?Qm1CcmFZTzlGOUpqVzU3dENsWHNuWUEvbnNzRGhiUVBJT2JQb1l5WTUwVklm?= =?utf-8?B?Smp1WU1kM2tYTnNNNmdsNDhINFZQOEhQNXd4Y2lhY0VSMFZ2bDNVeVQzVUJt?= =?utf-8?B?TGpKMTdTYmVwK09WbDVnQXJRYUQvc0Q4TWwrbHpDWkVRQ3pHV2xOMUI2Z2px?= =?utf-8?B?VEpZZjRUM2k4YUNsa2xvZGdsdW1xWTR4MDNXaE9lVXVmRWtzcEFHOVVsWXBt?= =?utf-8?B?NzNEWElCcmorK2hUdTcrVHNwN0J6MW9vWXVQeStVUG4xdytNa1lOUDFuRXVi?= =?utf-8?B?OUdIdFdnbTNJei9BVkVLUUJaclRKTUtWVWlHUVBPVVRaSVEvam5YZz09?= X-Exchange-RoutingPolicyChecked: bpMPtWpvNTHlUdmXIe1EeUJAaNOizlB1COS6u/CU83u6anrK9q+EBJ4HpQ0AGKk0px/qqASc4w6n3FgaaqG+Y+5QiwwsPFp9KImIgQzJnpLhragDF0Et/oq7LurHjAYWEGObTDK3r93vg8RvWIrjVLcwWaTP+24vlpxoVtRLKk18M0zsSR2y3v6wWDbjqxLFelI/Eo9fkUj9C/M7CxJ84+EZ8bL/pnFlyPYnpnHZeD1eF7+56zcAF8tMLCXL0rKcLjaFjBMAbSJPPrOo9xFJlyrEJYL2csRw0PLS50k22WylWI/EvA8s40Bk2DDNqZ3XVj8lyhYkAn5jaqamPDnoQA== X-MS-Exchange-CrossTenant-Network-Message-Id: 2f74eb0b-a7c0-4d6d-ae70-08dee1bb46b5 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2026 15:19:19.8894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vBmRGvIsy4Um5q98/5SYbTJXWo/XbkPDj4MhHH39ePYY6a84irhsjw1qa9x82HsMJHZdoO7wO2xHB1xIRDcvhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7471 X-OriginatorOrg: intel.com Hi Chenyu, On 7/11/2026 7:42 AM, Reinette Chatre wrote: > Hi Chenyu, > > On 7/1/26 6:45 AM, Chen Yu wrote: >> From: Anil S Keshavamurthy >> >> Parse the ERDT (Enhanced RDT) ACPI table so enhanced RDT features can >> consume firmware-provided domain information. >> >> The ERDT may contain these sub-tables: >> >> - Resource Management Domain Description Structure (RMDD) >> - CPU Agent Collection Description Structure (CACD) >> - Cache Monitoring Registers for CPU Agents Description Structure >> (CMRC) > > How should "The ERDT may contain these sub-tables" be interpreted here? > This sounds like some high level partial description of ERDT that is > not specific to this patch. > I planned to add some background context on ERDT. Let me remove unrelated content and change the sentence to: Parse the RMDD subtables within the ERDT ACPI table and their nested CACD entries to construct per-domain CPU masks. >> >> There is one ERDT per platform. Each RMDD describes one resource > > "one ERDT" -> "one ERDT table"? > OK. >> diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c >> new file mode 100644 >> index 000000000000..6405df9be817 >> --- /dev/null >> +++ b/arch/x86/kernel/cpu/resctrl/erdt.c >> @@ -0,0 +1,271 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Enhanced Resource Director Technology (ERDT) >> + * >> + * Copyright (C) 2026 Intel Corporation >> + * >> + */ >> + >> +#define pr_fmt(fmt) "resctrl: " fmt >> + >> +#include >> +#include >> +#include > > Which parts of cpu.h are used? > It was used in previous version but not needed in this version. Additionally, cleanup.h and err.h can be removed as well, I will drop them. >> +#include >> +#include >> +#include >> +#include >> +#include > > xarray is no longer needed? > Not needed, will remove it. >> + >> +#include >> + >> +#include "internal.h" >> + >> +static LIST_HEAD(domain_info_list); >> + >> +static bool __erdt_enabled; > > Is double underscore needed? The double underscore was used to prevent name collisions with the existing erdt_enabled(). Let me switch it to a single underscore instead. > Could you please add a comment above the variable to describe what it means when > "erdt is enabled"? > OK, let me add this: /* * Set when the ERDT ACPI table has been successfully parsed and at least * one valid RMDD domain with a CACD cpumask exists. Cleared on teardown. */ >> + >> +#define ERDT_VALID_VERSION 1 >> +#define RMDD_FLAG_CPU_L3_DOMAIN BIT(0) >> + >> +/* Bitmask of valid sub-tables found in the first RMDD, used to ensure all RMDDs match. */ >> +static u32 valid_subtbl_mask; >> + >> +int erdt_get_max_rmid(int cpu) >> +{ >> + struct erdt_domain_info *d; >> + struct list_head *pos; >> + >> + if (!__erdt_enabled) >> + return 0; >> + >> + list_for_each(pos, &domain_info_list) { >> + d = container_of(pos, struct erdt_domain_info, list); > > (list_for_each_entry()?) > OK, will do. >> + >> + if (cpumask_test_cpu(cpu, d->cpu_mask)) >> + return d->max_rmid; >> + } >> + >> + return -1; >> +} > > Using a CPU as parameter to determine the maximum RMID supported by ERDT is > unexpected. Looking ahead at how this function is used I find only one usage: > rdt_get_l3_mon_config() { > ... > /* > * Currently assume all CPU domains share the same maximum RMID > * value from the RMDD table, use CPU0 domain's value. > */ > int erdt_max_rmid = erdt_get_max_rmid(0); > > From this usage I do not see any reason why to do any CPU matching ... erdt_get_max_rmid() > could just return the max_rmid of any domain ... but that does not look right either since > the comment states an assumption that is never enforced in the code. > > Could this be made more robust by replacing the "per-erdt-domain max_rmid" with one global > "ERDT max RMID" to which all RMDD's max RMID is compared to *ensure* they are all the same. > If there is no such guarantee then I expect this will be the minimum among all RMDD? All seems > to point to there only being one global value that is determined during ERDT enumeration and > then this helper can just return that value directly? > Got it, let me switch to one global max_rmid = min(all CPU domains's non-zero max_rmid ). IO-domain RMID checks can be deferred for future support. >> + >> +static void __iomem *erdt_ioremap(phys_addr_t base, u32 num_pages, const char *desc) >> +{ >> + void __iomem *addr; >> + size_t size; >> + >> + if (check_mul_overflow((size_t)num_pages, (size_t)SZ_4K, &size)) > > I do not think check_mul_overflow() requires size_t type, does it? > No need to stick to the size_t convention - there is no risk of overflow, I’ll remove it. >> + return NULL; >> + >> + addr = ioremap(base, size); >> + if (!addr) { >> + pr_err("ERDT: Failed to map %s at phys addr %pa (size: %u pages)\n", >> + desc, &base, num_pages); >> + } > > (unnecessary braces) > Will remove it. >> + return addr; >> +} >> + >> +static void erdt_iounmap_domain(struct erdt_domain_info *domain) >> +{ >> + for (int i = 0; i < ERDT_MMIO_NUM_TYPES; i++) { >> + if (domain->base[i]) { >> + iounmap(domain->base[i]); >> + domain->base[i] = NULL; >> + } >> + } >> +} >> + >> +static void cleanup_one_domain(struct erdt_domain_info *d) >> +{ >> + erdt_iounmap_domain(d); >> + free_cpumask_var(d->cpu_mask); > > free_cpumask_var() does not look right ... it is for stack usage, no? (more later) > If I understand correctly, cpumask_var_t can be used for both stack contexts and dynamic allocation? Depending on whether OFFSTACK is defined, it may either be a dynamically allocated pointer or an inline single-element struct cpumask array. That said, since erdt_domain_info itself is dynamically allocated, embedding cpu_mask inside erdt_domain_info would be clearer. Let me change it. >> +static __init bool parse_rmdd_entry(struct acpi_subtbl_hdr_16 *rmdd_hdr) > > nit: what is motivation for the "entry" term? this is only occurance of the > word "entry" in this patch while RMDD is more frequently referred to as "table" or > "sub-table". > I previously considered the RMDD table an entry within the parent ERDT table. I’ll change the function name to parse_rmdd_table(). >> +{ >> + struct erdt_domain_info *domain_info; >> + struct acpi_subtbl_hdr_16 *subtbl; >> + struct acpi_erdt_rmdd *rmdd; >> + u32 subtbl_mask = 0; >> + >> + if (rmdd_hdr->length < sizeof(*rmdd)) { >> + pr_warn(FW_BUG "Invalid RMDD length %u\n", rmdd_hdr->length); > > Please include unit, similar to equivalent ERDT message. > OK, will do. >> + return false; >> + } >> + >> + rmdd = (struct acpi_erdt_rmdd *)rmdd_hdr; >> + >> + /* Quietly ignore non-CPU-based L3 domains */ >> + if (!(rmdd->flags & RMDD_FLAG_CPU_L3_DOMAIN)) >> + return true; >> + >> + domain_info = kzalloc_obj(*domain_info, GFP_KERNEL); >> + if (!domain_info) >> + return false; >> + >> + if (!zalloc_cpumask_var(&domain_info->cpu_mask, GFP_KERNEL)) >> + goto cleanup; > > Similar to free_cpumask_var() this does not look right since the cpu_mask is not on stack here ... > (more later) > Ok, let me switch to struct cpumask instead. >> + >> + domain_info->base[ERDT_MMIO_RMDD_CREG] = >> + erdt_ioremap(rmdd->creg_base, rmdd->creg_size, "RMDD ctrl base"); >> + if (!domain_info->base[ERDT_MMIO_RMDD_CREG]) >> + goto cleanup; >> + >> + for (subtbl = rmdd_subtbl(rmdd); >> + subtbl_valid((void *)rmdd + rmdd->header.length, subtbl); >> + subtbl = next_subtbl(subtbl)) { >> + switch (subtbl->type) { >> + case ACPI_ERDT_TYPE_CACD: > > It is quite subtle that there could be multiple CACD tables. Could this be highlighted with > a small comment? Something like: > /* An RMDD table has one or more CACD sub-table(s) */ > OK, will do. >> + if (cacd_init(subtbl, domain_info)) >> + goto cleanup; >> + >> + subtbl_mask |= BIT(ACPI_ERDT_TYPE_CACD); >> + break; >> + default: >> + break; >> + } >> + } >> + >> + if (!subtbl_mask) >> + goto cleanup; >> + >> + /* >> + * Require all RMDDs to support same set of sub-tables >> + */ >> + if (!valid_subtbl_mask) { >> + valid_subtbl_mask = subtbl_mask; >> + } else if (subtbl_mask != valid_subtbl_mask) { >> + pr_warn(FW_BUG "RMDD sub-table set does not match the first RMDD\n"); > > Would it be useful to print the domain ID to help diagnistics? > OK, let print the ID of the first RMDD and the "broken" RMDD. >> + goto cleanup; >> + } >> + >> + if (!rmdd->max_rmid || rmdd->max_rmid > INT_MAX) { > > rmdd->max_rmid is a u32 so INT_MAX test is not clear to me here > I overlooked this, let me remove the INT_MAX check. >> + pr_warn(FW_BUG "Unreasonable RMDD max_rmid %u\n", rmdd->max_rmid); > > Is there a limit in the spec? > The spec defines it as a 4-byte value, so a u32 here should not overflow. >> + goto cleanup; >> + } >> + domain_info->max_rmid = rmdd->max_rmid; > > As mentioned before, instead of a per-domain RMID, could there be a global ERDT > RMID that is initialized by first ERDT domain and updated/compared with every following > ERDT domain? > OK, will do. >> + >> +void erdt_exit(void) >> +{ >> + struct erdt_domain_info *d; >> + struct list_head *pos, *n; >> + >> + list_for_each_safe(pos, n, &domain_info_list) { > > list_for_each_entry_safe()? > OK. >> + d = container_of(pos, struct erdt_domain_info, list); >> + list_del(pos); >> + cleanup_one_domain(d); >> + } >> + __erdt_enabled = false; >> + valid_subtbl_mask = 0; >> +} >> + >> +static __init int enumerate_erdt_table(struct acpi_table_header *table_hdr) >> +{ >> + struct acpi_table_erdt *erdt = (struct acpi_table_erdt *)table_hdr; >> + struct acpi_subtbl_hdr_16 *subtbl; >> + void *table_end; >> + >> + if (erdt->header.revision != ERDT_VALID_VERSION) { >> + pr_info("Unsupported ERDT table revision %d\n", erdt->header.revision); > > Would it be helpful to print what the ERDT table revision is to help diagnostics? > Yes, it will print the revision, do you mean print the expected revision? pr_info("Unsupported ERDT table revision %d (expected %d)\n", erdt->header.revision, ERDT_VALID_VERSION); > > Please add documentation here that describes each member of struct erdt_domain_info. > OK, will do. >> +struct erdt_domain_info { >> + void __iomem *base[ERDT_MMIO_NUM_TYPES]; >> + cpumask_var_t cpu_mask; > > Should this be struct cpumask instead? Compare with struct rdt_domain_hdr. > When evaluating cpumask_var_t, please read the detailed comments above its > definition in include/linux/cpumask_types.h - specifically note the start: > *cpumask_var_t: struct cpumask for stack usage* > Yes, let me switch to struct cpumask instead. >> + int max_rmid; >> + struct list_head list; > > Could you please rename this to be "node" or "entry" to make it obvious that this > is an entry of a list? This is not consistent in resctrl but really helps > when reading the code. > OK, let me rename it to "entry". thanks, Chenyu