From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (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 1E7EA3A641D for ; Wed, 19 Aug 2026 23:04:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.9 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787180682; cv=fail; b=VsCDXIlbZHUuoXXUw0wzdKt2Ob6BVDkwQqugjsKjBmTfTeN0Qp2rW9QsR4OEli2ZleQxY9z3sGUwAdFmeljGmKJTcZvazoyObA2UzeW/cdWaYf/Keh0Ch7bgFHaLG4GslOOPLwWydrk31gHpSVdL5qNyDZhyWeYqqcJI/+4KzD8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787180682; c=relaxed/simple; bh=p3ond1If78vd329+Tzkc2JS4YirTd7+qBbtKIJcMAiM=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=Z7SFJ4ibLAIabOB5L6CXy8kPO4tqFh3pfAEUuLXfjXcxNKkdXJTHtR1dnuv8SItLwxzZBID6dHkNz/1ll0oDqI0VYFfe/CJwurObtGd7o6dwTveR3TMZiYYYzXlFJ7dRCyzpasvBcQYKUgD1oecmQMKT7d+vNirpPePSApiiJsw= 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=bVIzvzup; arc=fail smtp.client-ip=198.175.65.9 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="bVIzvzup" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1787180680; x=1818716680; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=p3ond1If78vd329+Tzkc2JS4YirTd7+qBbtKIJcMAiM=; b=bVIzvzupit4vNANeqzvBOFOQqXAZ8CMEGq4HjSvAs6PgeOBn7fbZHoIV ++h44q5sMooIGaZA0/L8RedPV6YCOfgTgJto8xcTKGn+oONH6B0ImbkaL 0QJ8Aqyr9Zv3GWTfo2twM2w79K7NU970XZJWJ6WucC3VQIgDTwheemewl BGh/F6IFOf0/VxfpWmc2zTCagnEOPar5jn1NawGvsoXW+bIUGlETuDej9 +FqNdcAwp4M3o/HiNB250b/2Ev3W3SQr9gemtxDrjoYmqJoKXQelLfc1G z0PU7Cdbgz9rVLVMjehA/hngP1MTtyf5meGUm7SguazGtkYqGB8vZvzP5 g==; X-CSE-ConnectionGUID: +gWSyv18QSmbwaE9dRBK3A== X-CSE-MsgGUID: xcABJrdFRTy6/yGoC8e/Yg== X-IronPort-AV: E=McAfee;i="6800,10657,11880"; a="110494631" X-IronPort-AV: E=Sophos;i="6.25,232,1779174000"; d="scan'208";a="110494631" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Aug 2026 16:04:40 -0700 X-CSE-ConnectionGUID: DiZbg74iRYmstlUBls650Q== X-CSE-MsgGUID: /w2AMmfST+GDQhT5PiLEew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,232,1779174000"; d="scan'208";a="269220751" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Aug 2026 16:04:39 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) 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.45; Wed, 19 Aug 2026 16:04:38 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45 via Frontend Transport; Wed, 19 Aug 2026 16:04:38 -0700 Received: from CY3PR05CU001.outbound.protection.outlook.com (40.93.201.36) 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.45; Wed, 19 Aug 2026 16:04:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mhyWrjmiBPICIFh5glWVkFaKnNep/AJ1RNg2FkZIzXnwRUOS7GUv1ixlkMS8GQDOK40afNzA9BstjoNgbREDsJ6TPUQmpLf5eXlj4L0zNAzfwntf/JvsTwR5E7b4Yi4Iy/4Vp2FFJ/rPI3XNhB3pb6/jIKQx59Hb78l9BrixlILYZA/5BygsvgPOLOKbMv7QdLafyqHpn5FYQEfL2bsrsGFL0tdIL8lvtVNqiuoklhnZEEGMKAjKRNjd9TFfiBhsXWqQI9LiQEtm7RUWOXXS0r2fiH63ENYPYWBFZHTJdQvrySbAsnAH0GiDGZAV4j95+UpWi1nfuBQpe+OBFLHSsQ== 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=uA8KJFV1OoIR/x0r4Wpw8BM27M2Ks96DLfw15IZQmzQ=; b=RKwETD1q8/I+dpeVqsIcscsdsKbxDkwbU2pvrt9e3T5TO3xQEgQ83f7GBvuITOpj5GQs0JKHbjr5L4uDvzYtw7D/watusYkk6NpI2s+xbBSdG/W3XNMTQA2PGcAbgjPMt27vIgKy2MYiw/uCQLmQpNYC8H2m9pYmiY3Jck8XkkSHroCygmtjQsfpoUlT+V7NetWA88ZsTneAcXuyxko/e4Ojl5hO4n2eGOjsIyiwfZUswhlfKkiMZ+ap6eY/QU5ucXseWNKE4YHqNxmatxafh0QjLlafb4MfQFmZsIJvnZDFbG/PxvULIcTRF2ot+wKovPyBFxCXQhTXJJuAqZwYNg== 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 SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) by SA0PR11MB4672.namprd11.prod.outlook.com (2603:10b6:806:96::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Wed, 19 Aug 2026 23:04:35 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%5]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026 23:04:35 +0000 Message-ID: <86349d88-2ddf-4849-bbd8-1c7371a73f09@intel.com> Date: Wed, 19 Aug 2026 16:04:33 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/9] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online To: Chen Yu , CC: , , , , , , , , , References: From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0072.namprd03.prod.outlook.com (2603:10b6:303:b6::17) To SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) 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: SJ2PR11MB8370:EE_|SA0PR11MB4672:EE_ X-MS-Office365-Filtering-Correlation-Id: fc3fdb3a-03d8-4305-faf1-08defe463ccb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|7416014|10067099003|56012099006|6133799003|3023799007|5023799004|11063799006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Tv2GrdGLe1ijUrk4CM9qHtK+PCi4ABQLkXy0C58i/RZ/skho9FyAzgw6cm8AgdW9d2ccZcD+nKIGhkWpCjuDzmKDK2IbFuEfrayquqjcibxBgK3k1ThZLbDOkHsE1X/7zQU+Okci6dAnQxtHFy2zyL08fgWztTpVs4tOGKUH/Rdjaz/avZ3GrWa+U9MyzdUrjcdSSAWGO7t9+nxswqL0jk8bnVS1Q6l8/MQ80tKGcwmeT2KAproT96I3iMhg1Q556rz9yKl5M0YEdN5kJi8sliIrycYp5PCQ8sdRJFEZN5oTiMUkVkn3XSUQal3Y32J+7XLlR+C5Mi5yC7n6k1eCgpH/SUhEiZQZhPEXSM3TLWtVAUTrf+GsSDo3GlaY/BFCJEOCwVdfnZTtDUB9hcYccCU4nQLRPePKWC/gAng+o1e9n5r3coIA5s+hOCVwvR1BIpIPGQyu1RKo5SXLzIA04s3jrPl2zownrLmdAgmyxSJL0Guqdd9cMDN/ilc/Z3YCJgHVc7xUgjasNVrHHclN4Hdrr40rozg0C/wERltwMN1ZK5riQNnfVCtYPqvG+wXFWEx68mSlgmmNzB1TRw7eHytWnF6cLRGn9Lpj6btbKsyQFAFf6IqP01BUYsBwvJfVRQq2MqQ8R70fXK1xOXxy1ub4PpFhV6TZpKP3+nZWYv4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB8370.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(7416014)(10067099003)(56012099006)(6133799003)(3023799007)(5023799004)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2Zsa3dUN05zOElrVmxkM3R1WU1uVFV3YzluWVZqYkdPVmVBVlZ5ZXpGbGlU?= =?utf-8?B?NHNDMFBIdU9qU2M0aHI2YUJ0aHRLYzJiMi9tZW9qZXpJLy9XUkwyMUdHdUsz?= =?utf-8?B?ZVJrdER0MXp1SlR5VGlXeHNSVEZVOVY4RGVUZ09tTmo4MFl2U0d3dVFSM1l4?= =?utf-8?B?SEtiZ084Yk1vdlRoV2I2RDdoWXFCaEE0bk00VitmTjg5L2tqYkErWnJRNFVk?= =?utf-8?B?MW1HMVVhSkxSQnM5bFdRMTFGYTUxb3lrUWtYT2VXY3U1QVRudzdnUmdTdkpM?= =?utf-8?B?WVpmcDhyWU56NXppVlBtUml2V0R5dXFIZm9ScDI1czBwZmNSSEg2aFFIWWZz?= =?utf-8?B?VEM2M0tZU3pESndleEMrLzZXNFZRQzRTYjZ3R0w5UTg0UmZCVTZBOG1UWkRu?= =?utf-8?B?eFN2c1p5OU92NVhWc2ZRL1YxendVNGk4WXZ5ZWh5ZXZOUnhMMGxVQTJBWG9q?= =?utf-8?B?bkp1NEZNZk50QnRuMC8xWU5BWFlJTmY2RnpRNHFIUGp3eU8yckdzRVg0WlRU?= =?utf-8?B?OGMxK3pPN1dadEdDK3UrY0lFNjlRaUFBcVlWUWlpaEhtbWpvbUE0THVWNTlG?= =?utf-8?B?Sm0zZzFkbnpjTVQ1VkE3UGF0Z1IzdkFnaFFiTWt1NFRadmhrenZLN2psTWF4?= =?utf-8?B?cW4vRFZuZHRFbnlvbjNqd1VFT010aEZvZEpjQUtmbXEyck80V1Y1dEl3OEMy?= =?utf-8?B?VzZVMzgwWmRaN2tWYyswdEo2L0oxTis4Rk1EeTFIajhjcXNhc2U1NGI0RFNj?= =?utf-8?B?dXV6ZXdOR2dxSnBseWxUZElKYUtuS2RicHM5UUxsZmMvS2dOQVJ5UGFRMmw3?= =?utf-8?B?MlRaTEdweFFLdHFQeU1laEFzUDdrOTdGakRnU0hmYUtYbzFMdXVNVDZ5SU1k?= =?utf-8?B?MlFQT0tCdlM2blZPY0I0a3VNSnBvUmFnWjZDb3NWVURRWi9DcW8xS3BiWUFB?= =?utf-8?B?RVhYdmF2UlBKSVVmb2R2bVp4akFncGFRZEpJbjdCVXJVQTNZUmphaWdxOHFt?= =?utf-8?B?aWFVUDVsK0VkMGZuMmFTNFAvNXQ0U2w5dXk5enNpUW9DWStUZGN5TUE0Uy95?= =?utf-8?B?NHFza252MFBwcXRMd3NxVzhMdFJ4UDgyUzhYbGpUNGhnbENHMUdXeHJpTzNT?= =?utf-8?B?UC8rWGpiWElua042RzRqLzBxODJhcTc1SlpFbS9QOTR4UW9jeVVwa3BiNEJ1?= =?utf-8?B?bVFqQWhTR1p3NFk0d1psSW40QldTc053emtPSzIvNkEzVm5XaVI0bVpkOC9Z?= =?utf-8?B?cm1hSk5Ob0NxYnJBZC85UDdPRENwaVdUUzE0d0VxK1g2N3BaaUtGSlZveC92?= =?utf-8?B?dnE3cTVsa1BDdmJYc0xpSVZYMW5ZRlFrMlVFbzBUcTNURksyaDBVVDBmVDF3?= =?utf-8?B?ZlRvRDJzTHpZaWsvNE1USXlzNkEwNGo3Sk1GWXdUQXVwOXh5NGRxTm5VU2N2?= =?utf-8?B?Z3dYbWxyT1dZRVhqbWFoRkNiTm0zaWlGUFZpZnF5ZUVPOEJ3bHlmdm9mYzdu?= =?utf-8?B?dUljalFKelJ0N0RSYnVGSmlYeFp1NmZKanZNTkJXUmJveFhoV1dvV3dVZ2JY?= =?utf-8?B?TjUzVVZ4M1lVZFFaWDMzanN0UVFJZXU0SlFlQXdGdmREMXd3VzlYQzViS3NN?= =?utf-8?B?QTVaMGVBWmJ5YzFQaXBSdVVOc1h2L3paeGlGZEF4dGhha25BTnpDRTRheHVa?= =?utf-8?B?ejA0bkVQdnY2TFFNUWw2ZnJ3VjhSSjRBbXZsd0FYYjAzZFZvQlRxZVlUVVdz?= =?utf-8?B?bUdiaXBjVGNFYW9uc0pFdDU2cGRIUlVIUjRUL1I5cFRMRmxzUVp1dlc4WW9r?= =?utf-8?B?L0V4VWM5Y2thVG5GRjEybnEwUTBjM2VIS1VKdjNtL1U0ZWJiL2R4aCtFTVBj?= =?utf-8?B?WDhqdFhuZkozWlBFUitwc2VzUDYvaGFjRTU1UUFxQjNNY1FvR1U2VzdkcGpJ?= =?utf-8?B?R1JQakdXNE1WN3lkSTdsVkpUc3A4bzBHQ3NsYnJMR3lqV1Jzbi90UFJ0YWRY?= =?utf-8?B?cGpEYnZBYTU2R1JONUVHemxVazV4cnBPbWVETkZrTWRVVnF4TFpHcEZoUGp6?= =?utf-8?B?RkdXWFNrcGhGdGxNeTFCTjlkVzZFcWdXM3Y0YW5tNUo5SHhja3hOUDJKeGQ3?= =?utf-8?B?QWRnNGJpZ0V4bEprOHFpU0lLRk02VVhRdUpMT20weW5wRzQzRy9LQ1RIUVcw?= =?utf-8?B?azREWFZ0VDFMeEdLSEtNTUVFVk9PT0wzR2Y2QXBSWW5rcTlQYmVHcXU2dGwv?= =?utf-8?B?VGFXb0QyUWd6OE5maGVLTWZGZFM3K1JMZ252UmFoTG95d3R2Y01KeVR2eWto?= =?utf-8?B?UUVzdnNTVmUxVys2Y0FqZnVJUnQzY1dkbkVwYnArQy9taElrUkFnaCtVeFJx?= =?utf-8?Q?QdrbtICI0BWxXkeM=3D?= X-Exchange-RoutingPolicyChecked: bRpUZuD0GrTnGQb9B/9r2pgRX1pu1u+1jcpeHbf2TaF5VjEvvzKcXbdL0nGwrvSqV4QSswTDuQ6bAWqTTILKzVCD7zmimVpFSHA+TQpi5+UPX6/HfxDAl7SFzFA2NIhyQHWHMTvcE7eWRFYlynMb2rSjarj0jpyiZ7V56zWpvyrTTE5Fr0miTW+oeNaaB95KTqjSlJ5ABPgUBGAKkT2DmHe8AqIG+QywmfoXl/Se/ooTKqdLy1xI/9Tl9dVTbGtXeZEhgskK1cNhU/iy7ps/gkRsZS8Z5dcaxlNb6BikIevTh+HPRbTYelzy6o1RCpxmvH2De9N6qqhdzwYzodDwhg== X-MS-Exchange-CrossTenant-Network-Message-Id: fc3fdb3a-03d8-4305-faf1-08defe463ccb X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 23:04:35.5717 (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: z7Ba1pLdcU9PwxJUQMITPfLSKvc3nthkC7iiVg+u7GV5mgJ3Q/GN9Puzf6l0Bc49/sl+xNFMbM6kbUh2TkK7Ks7TgPu/bKNOLsMYhp2N/qU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4672 X-OriginatorOrg: intel.com Hi Chenyu, On 7/25/26 2:23 AM, Chen Yu wrote: > Reading LLC occupancy counters via MMIO requires the per-domain ERDT > information, parsed earlier from the ACPI ERDT table, to be reachable Please avoid using terms about a patch's position in a series. You can just drop "earlier". > from the resctrl L3 monitoring domain. Nothing links the two yet, so > the monitoring code cannot locate the MMIO registers of a domain. > > ERDT and CPUID enumerate CPU-to-L3-domain membership independently: > CPUID leaf 4 describes the L3 cache topology, while the firmware CACD > sub-table lists the CPUs of each ERDT domain. Both views must agree on > a CPU's L3 domain for that CPU to be monitored safely. > > When a CPU comes online, validate that firmware and CPUID agree on its > L3 domain before adding it to a resctrl monitoring domain. Exclude the > CPU from all monitoring domains on a mismatch because a topology > inconsistency between ERDT and CPUID indicates a firmware defect that > makes the CPU's domain placement unreliable for any resource. Otherwise > attach the matching ERDT domain information to the L3 monitoring domain > so that later code can read monitoring data via ERDT and its sub-tables. (similar comment as above) "so that later code can read monitoring data via ERDT and its sub-tables" -> "so that monitoring data can be read via ERDT and its sub-tables" > > Suggested-by: Reinette Chatre > Signed-off-by: Chen Yu > Tested-by: Hongyu Ning > --- ... > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 23925bcd71d7..c2568b29474e 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -580,6 +580,9 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) > return; > } > > + if (!erdt_cpu_valid(cpu)) > + return; > + Including this check in domain_add_cpu_mon() means that it is repeated for every monitoring resource. I think this check only needs to be done once? How about moving it to resctrl_arch_online_cpu() where this check can be done before cycling through *any* (monitoring or control) resource? While domain_info_list is initialized early, this validity check makes concurrent changes to it so locking is required. The current implementation already does this modification with domain_list_lock held but it is not made explicit that this list is now under the protection of this lock. Please add a snippet to the comment above the domain_list_lock to document that it is now also used to protect domain_info_list. > hdr = resctrl_find_domain(&r->mon_domains, id, &add_pos); > if (hdr) > cpumask_set_cpu(cpu, &hdr->cpu_mask); > @@ -589,8 +592,14 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) > /* Update the mbm_assign_mode state for the CPU if supported */ > if (r->mon.mbm_cntr_assignable) > resctrl_arch_mbm_cntr_assign_set_one(r); > - if (!hdr) > + if (!hdr) { > l3_mon_domain_setup(cpu, id, r, add_pos); > + hdr = resctrl_find_domain(&r->mon_domains, id, NULL); > + } > + > + if (hdr) > + erdt_l3_mon_domain_setup(cpu, hdr); The additional search for "hdr" seems unnecessary. Could l3_mon_domain_setup() just call erdt_l3_mon_domain_setup() directly? > + > break; > case RDT_RESOURCE_PERF_PKG: > if (!hdr) > diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c > index 8998cae47090..6257869d0db2 100644 > --- a/arch/x86/kernel/cpu/resctrl/erdt.c > +++ b/arch/x86/kernel/cpu/resctrl/erdt.c > @@ -207,6 +207,72 @@ static __init bool parse_rmdd_table(struct acpi_subtbl_hdr_16 *rmdd_hdr) > return false; > } > > +bool erdt_cpu_valid(int cpu) > +{ > + struct erdt_domain_info *d; > + int dom_id; > + > + if (!erdt_enabled) > + return true; > + > + dom_id = get_cpu_cacheinfo_id(cpu, RESCTRL_L3_CACHE); > + if (dom_id < 0) > + return true; Should this be "false"? Perhaps also with a warning similar to domain_add_cpu_mon()'s warning when the domain ID cannot be determined? > + > + /* > + * Find the erdt_domain_info that contains this CPU, > + * check if all CPUs in erdt_domain_info's cpumask > + * have the same id(L3 id). > + * > + * For example, erdt_domain_info reports: > + * domain0: CPU0, CPU2, domain1: CPU1, CPU3 > + * rdt_domain_hdr reports: > + * domain0: CPU0, CPU1, domain1: CPU2, CPU3 > + * As a result, CPU1, CPU2 should not be covered by resctrl. > + */ > + list_for_each_entry(d, &domain_info_list, entry) { > + (unnecessary empty line) > + if (cpumask_test_cpu(cpu, &d->cpu_mask)) { > + if (d->dom_id == -1) { > + d->dom_id = dom_id; > + } else if (d->dom_id != dom_id) { > + pr_warn(FW_BUG "CPU%d's id=%d not equal to CACD domain(%*pbl) id=%d, skip this CPU\n", > + cpu, dom_id, cpumask_pr_args(&d->cpu_mask), d->dom_id); > + > + return false; > + } > + > + return true; > + } > + } > + > + pr_warn(FW_BUG "Cannot find CACD domain for CPU%d\n", cpu); > + return false; > +} > + > +/* > + * Associate ERDT table information with this domain. > + */ > +void erdt_l3_mon_domain_setup(int cpu, struct rdt_domain_hdr *hdr) > +{ > + struct rdt_hw_l3_mon_domain *hw_dom; > + struct erdt_domain_info *d; > + > + if (!erdt_enabled) > + return; > + > + hw_dom = resctrl_to_arch_mon_dom(container_of(hdr, struct rdt_l3_mon_domain, hdr)); > + > + list_for_each_entry(d, &domain_info_list, entry) { > + if (cpumask_test_cpu(cpu, &d->cpu_mask)) { Any motivation for why the cpumask is used as a test instead of the domain ID? > + /* Assign the ERDT information to hw_dom */ > + if (!hw_dom->d_info) > + hw_dom->d_info = d; This should become obvious if this initialization is done from l3_mon_domain_setup() where hw_mon would have been kzalloc'ed. This means that if hw_dom->d_info is already initialized that there would be *two* ERDT domains that map to an existing resctrl monitoring domain. That looks to be something to complain about? > + return; > + } > + } > +} > + > void erdt_exit(void) > { > struct erdt_domain_info *d, *tmp; > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h > index bdff3ea36e62..bd437c3e5bf0 100644 > --- a/arch/x86/kernel/cpu/resctrl/internal.h > +++ b/arch/x86/kernel/cpu/resctrl/internal.h > @@ -99,14 +99,19 @@ struct rdt_hw_ctrl_domain { > * @arch_mbm_states: Per-event pointer to the MBM event's saved state. > * An MBM event's state is an array of struct arch_mbm_state > * indexed by RMID on x86. > + * @d_info: ERDT table information of this domain > * > * Members of this structure are accessed via helpers that provide abstraction. > */ > struct rdt_hw_l3_mon_domain { > struct rdt_l3_mon_domain d_resctrl; > struct arch_mbm_state *arch_mbm_states[QOS_NUM_L3_MBM_EVENTS]; > + const struct erdt_domain_info *d_info; > }; > > +bool erdt_cpu_valid(int cpu); > +void erdt_l3_mon_domain_setup(int cpu, struct rdt_domain_hdr *hdr); > + > static inline struct rdt_hw_ctrl_domain *resctrl_to_arch_ctrl_dom(struct rdt_ctrl_domain *r) > { > return container_of(r, struct rdt_hw_ctrl_domain, d_resctrl); Reinette