From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 0587920459A for ; Wed, 24 Jun 2026 23:44:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.15 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782344661; cv=fail; b=Cw7SMe2y07ieq+rTshs2WI22f5fD3kQGGttv22W8LsF72gH9sV6BSw01syjT1lYYDlpmAEifcxUeyVSioyyPZBZltwnjW+R0Ajfbe5E5lPYVI3fhdF2lX/PSQSgssBxix/inousEnIKK6UhR+7MITKhPRVW6FAjYy48jEH2Bbko= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782344661; c=relaxed/simple; bh=cFlQ0CoPwkfrBiOTDH2fUkV3GnuCTyoXjBe64rHLLNM=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=MEMeodG1ybrrbQtIWU354WIMaDudlHCceWwbg4IS87VSgh5BIGnMaJvFlCeph7vYZbT9yvxj82Nn+1sJlXYWjrSrfAlYhZJx+yvkgfOA052RpbSxaw45dY3nQnQLStJpv0Gm15XV4cwvP9CqeFIW885YPhHambprUDMXERei2Vg= 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=Amn5vgmV; arc=fail smtp.client-ip=198.175.65.15 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="Amn5vgmV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782344659; x=1813880659; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=cFlQ0CoPwkfrBiOTDH2fUkV3GnuCTyoXjBe64rHLLNM=; b=Amn5vgmVl0tL1osPzjKb2esqRraidJLV1M7PRonjgXxf2QkhH7rTjWtk I3YqA767IQtRQJaFjgJpLPPJDKRnCurBi5Ba8YNzJBhdDV0jB1jsAzgbj FFdqP8dC8Cu4AD6qvrasEnm6W2vNu5SXU2IWT3mwZXRsWwnzgSM416aem thp0wx671dVDBLSX4pa2GSj1EGEMgFfDTDBTVWqyx9Hbm6hyGuqBzPbQ4 AO9tBgYDRopWdltDjrdSROy7ytBZjvBp/+4wGL8EUAMgRWOg2JVSanVC9 KTOR+kLQJLiTxjI4VVnchJFPM6xJKkDRBiAYrTTw/5AB909i3oAHlrcax Q==; X-CSE-ConnectionGUID: b1XDehvhRYKfBGjBAdIs/A== X-CSE-MsgGUID: 2jjNbj5AQYOBFgRBasMAIA== X-IronPort-AV: E=McAfee;i="6800,10657,11827"; a="86796787" X-IronPort-AV: E=Sophos;i="6.24,223,1774335600"; d="scan'208";a="86796787" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2026 16:44:19 -0700 X-CSE-ConnectionGUID: 2rdqtCDORv60BVprT+UrUg== X-CSE-MsgGUID: dK1hEMbUR5eiujaqURwLuw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,223,1774335600"; d="scan'208";a="288255164" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2026 16:44:18 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Wed, 24 Jun 2026 16:44:18 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Wed, 24 Jun 2026 16:44:18 -0700 Received: from CH1PR05CU001.outbound.protection.outlook.com (52.101.193.19) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Wed, 24 Jun 2026 16:44:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sWTAoQ3LKpbXWoEw7DBgzI6JvUI8ZTqZYuF4xaJbc6Ug1zrAH7TF96e2luuwXRtPsL7usGmDHbcoGPcE3Nm9kq/pnacKRI0QlCaeHvEnqkfi2NokoyXUpEUrkgZ9UjLxk5JIGn26FmiX2H/r4Aie/6p+qqO1J71ipn6kWN9pSal8GAxiYA2mTxYYGd8yes7Cu8jiGBUCPQrsAPZVEzMgBq2UfE6CYUjBMMzV+h79KsqLli5qM/aiXthrFtWRDqG9Mxmor52RmnVIWqFZVhK7GcxVbF6jZi23zAM5zFrIuB1OgA5xf4JwdPWe3Pwfj0wCrKM8SCROn+87EMajOcljcw== 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=SMGhQuZ3JT8oVHUbNrDSDpUWrcI5I7hHk9M/VHtnssU=; b=eBee7pkpjzTHzgwrCuxb56lX1iwUzrpniaNZffPRy0ps60x7P0J1MAh3fNHIxLj29Oyd76cnHhUcU1LJAE+YBWKnezGRo6Lc4rRqb6lwzJ537Wb3Ce3rz6gi61LErvr2dVT02pP2fcADVdaHetT2TOJTTF8SdSjJToZUEXFVDw534QT1X8FSJeJCavNccmLY6wvyniBwFMNWmvgrMveNu2WB9re1TRzooLhafFDWdAeqWbJ1AdYdxSLbz3goLBn3YqeZZp2Fw++g1SV90ZZ6bJ3mldP+E8FP/gsnTda2Qq/L3pP1idSYcL4kovwJTJVr/MJc6x+zG2vHrnOpp7BTdQ== 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 SA1PR11MB8319.namprd11.prod.outlook.com (2603:10b6:806:38c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.159.13; Wed, 24 Jun 2026 23:44:07 +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.0139.018; Wed, 24 Jun 2026 23:44:07 +0000 Message-ID: Date: Wed, 24 Jun 2026 16:44:05 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID To: "Chen, Yu C" CC: , , , , , , , , , , , , , References: <807a91c2b6235f85e2d19d4293c17e53a8cc69b2.1781332698.git.yu.c.chen@intel.com> <288153df-307a-40e3-96e1-ff4ae8f6bc5a@intel.com> <2835922f-d2b7-45dc-92e3-c6aed4e79fe9@intel.com> <4b48ec4d-517d-44d0-8be0-7e24d0970b7b@intel.com> <1c671ba2-501d-4b31-bd33-9cb23b54db01@intel.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <1c671ba2-501d-4b31-bd33-9cb23b54db01@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR04CA0245.namprd04.prod.outlook.com (2603:10b6:303:88::10) 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_|SA1PR11MB8319:EE_ X-MS-Office365-Filtering-Correlation-Id: 5bf0b33c-b9e9-4c13-910e-08ded24a7b3e 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|366016|23010399003|376014|7416014|1800799024|3023799007|56012099006|11063799006|4143699003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: /dOJMFRplz0jr0uro/jvLmGdk1phmj2D6meaZmGEObOqLje8M/fZdyjnOidxjJilatuCjgaLHslS++kGMSbZg07ChFFvOYy3fG38V8allyaK8Nal/8zNcmki0YvYa+xBc/LZ3nyb+fBWUgODHZ8P7oZ2hH8KENO1CgmuPrgx05fIeAibtNYngi0t0bEOVQSnTePs95RH/yyC2n0XQ9m66La10o/1c8+7tL8TbLYBvxQaSDvk3FG6u2gt4mVnfEAyM7hqul+hsnhB38JIm5hUlls+Oonb+lCLedlAEshdVba5Jv3N3PFfRMZXnO+2851uUI+vWI84/X5nla9zJO6/LvDwXc6BIFhoImX/z5AH1pHnIYyUTq5aDLsQnXNAXi32XA2tqUu+gpYI6PV1oBEAhkpkenrhXbwpq0dHguKFaTFgBF+946Y990Uyl/l4r+h08KQhpLFfjjQr863r34lm99/ONa+Ut5b8FQm3/EDWBYuRnFfm/Pc8nBduHXkc+JrjaPW9rNBPmuKwpHwNMkC2yor01GFUs4PV+F0ee48ylF9i9fY6lMGkDs/YdNa0oNCwqNv3vqTAGTMW0xUnGObiZGhh0h2keskq45Pauov1zGxrX7S1MbERn7j9TNecNwjfHrg3RMANI8gKApOh/77WwHmW0iWomaTyQwrBQI4UI5U= 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)(366016)(23010399003)(376014)(7416014)(1800799024)(3023799007)(56012099006)(11063799006)(4143699003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L3VLZWovSXNwRzBIb1pOeGM5VHdZTWZrQmllQ0FDdk5JY1JMRUVGcStNcGZJ?= =?utf-8?B?NTc1UXJlY00yeC9pVUROSDRoMGUyLzNxYkt0UU1oUGt5b3Y5akVsY2toZ3d1?= =?utf-8?B?YUg1ZzlMRTg2VFpFVDVKNWZzUWh4K0h0WDU3QnZlZWxzbzYvcjV0Umc1VkVS?= =?utf-8?B?Z0lFanV4alNicHM4WmlvWjVBOFE4RXBRU1FpNGJFL2RINm9weWJLVGZxRHVQ?= =?utf-8?B?NHo3Y00wMTVVQklXcklRS0hqZGo3dkNVNk04a2dWYkVsc29sZysrcDdoRitR?= =?utf-8?B?VXRBSHI0Y2lVV0JTSDh2TjBnZGMzTmFiRHkxdjdiLzZ2K1pKZ2lNVjlldEhO?= =?utf-8?B?NFRMaXZ1TUMwZzhEc3RhZEdRR0hBOU1DVWU5NTBneUlIK3NuZXpueGpJNEdC?= =?utf-8?B?M2hwZzJaRUlKTCtQRUxLRC9WS2lnTXY4SUFQN0I3d2FIazl3WXFQK3gzaXFp?= =?utf-8?B?L0QzMWUvcFNqS0RITG1YZGIwbHMrMHIzaWxJYmxzMnM1S09kYXhJazMxT3hq?= =?utf-8?B?WXRWb3NpbXI0UGdLcjN2Q3dNdmxyVlArVHh1bGQvQjI5ZlkrMzhnVVEwbXFD?= =?utf-8?B?cHg3MHdETmlIODh0NjRCZWFpM2UrNXdGenFhU0V2em9wdjFZUWU1clVENlBx?= =?utf-8?B?Q1hPVTljTjhtQW5hZmhEL0NRYjBObHpCb3J6c2ZFdVFYbkdjemdZaTJtd1JK?= =?utf-8?B?bDlhSzNsV3loMzIrQ1hBNlltY29heHdtZzdrZjBNdy96bmhnVk4xQyt1N2Zw?= =?utf-8?B?dm1mZ0psNTMxbWh5NTR6TndRLzBraXVyZG8wTkE2MW94WThzOEFhWFBWQmgx?= =?utf-8?B?WnZacXc1WW5hUENaZ1E0MC80cEFOMlNZQTlMY3R2M0NIc3VMK1VLZy8xbmMv?= =?utf-8?B?aytlYnZhajF5M3VGSVlDVEJHUW9Yd3l2Rkpsa0VFQnpzL0NlbitJYmdPK2Q0?= =?utf-8?B?UGdDWHRhSnhjWklCQTZSZXpKSjlOZXVFRkRCNnJMTldwSUpEbXR4aWp3dENI?= =?utf-8?B?cHRYS29hN2k4cmd3N2hzSDBMeVlNcHZmTFZnTmZZK3pMdmlyTXBCYXBkZ21v?= =?utf-8?B?WlFuTzBzd0Q4Z2pkWDJqSEMxbWhrMHYrdFNtVVBpRHhOZ2VwWVF0ZjZNNzRT?= =?utf-8?B?SzlGNXRkK1NoSlFkRGREVFFpMEZvNm04eXpTb2JRdGNFSElQSFZhQzFKSkY5?= =?utf-8?B?VWFNZzR5bkIvUlZNd0MrVklSdE9lcHJnS1FqRlhYdUsyRWRSSDMrbnkrbVdE?= =?utf-8?B?Q0lxbnFCYmszQWlZb2xHRDRuWDdzUU9HZ3FhbU01NG4vSmcvVzR2dWtjYkFP?= =?utf-8?B?enpibHdzSnNiMGh5aER1V1I5b3IzUE92VW4ySEJsMDk4RVdjM2MyalBoR3JZ?= =?utf-8?B?S2pWS1JVaDNMNmw4WnAwMlRhQzlPV2lUQUs5UmpCS3EzNmh6MTR1MGQ1Wkps?= =?utf-8?B?eEV1cHJnc2R4M3Vtdzd0N1dFWjRCUFVrWTFzeWtEdnFSRStadkREWkFyN3V2?= =?utf-8?B?OEEzTzRLWitKbXFTcmswaFJsZFFlYmVpZjJlbmh3dmFEbERCVFJ5blRza2lR?= =?utf-8?B?aUJ1Ni9MWlc1VTRLZFR3ZXZvTSsra3YyQWFxSXRDVklNMThPTGtpL2JzV0ls?= =?utf-8?B?eGoyaS9Pcm5oSjJBcUdQTDVucENOKzRZeUR5c2Jkd1EzUlo2eThKZ1lwd0ZR?= =?utf-8?B?QWhTRzFMZm5CcVhrT2hnZXM4WU1ZVWxjQWtpd0I1OWE1eDJDNy9qSXZxNS82?= =?utf-8?B?Sm9vTE1xejhvejBJYjFkU3Fwb2t5MTROcCttTE1EVU1EOEVqclFBR0dLLyti?= =?utf-8?B?am9YaER1dndXaG52TWNqWXF5U2F0aUpyTnUyRitKcE0vWDlWLzV1RTI1cUdr?= =?utf-8?B?VHdQajQ4YUlmc0VvQmNsbkl0VFZsT1o1QVFPZm5FMytCd29oeFlvaXlXNzFw?= =?utf-8?B?MkRGUlN2Q1JkM0daVlFUMlplZThqYWpzMU1XdmtIRHFnSkpBczQ5Sms4cG9a?= =?utf-8?B?QUZqZHUyaFhQVVh6aGk5NWlzYXlqOHBlejkrTXlESS92aXJjdDE1dW9HNHpR?= =?utf-8?B?aDN6K1FZai9oNGFaNkhEbW5jMnQrME1RdktjMXdJbmRxd3FQZ1Bwc05Ia2RM?= =?utf-8?B?S2NKZC82bmVkVVNaRjc0N1NyNXFmb2t1NHc0NmNyTytzcHQ1bkVUbHNnbjJD?= =?utf-8?B?UllCc1Myc0VjUEE4Nk40cU55OWZDajlYYXl1T0pkdHA1WWRFWnQzbHhEbjFC?= =?utf-8?B?WkFNa3ZNcmhoUEZMeUZnMDNIdGFVcm5jRXExbkE2Wnh1MGo5VEdta0QyS0xF?= =?utf-8?B?MytVWUxkZ2I2amFNRVY5Z2VaeG51RkxUc0UzQTBzNGZkSDhuYlpwVXBaclcv?= =?utf-8?Q?pbtEohJH/ihExRrE=3D?= X-Exchange-RoutingPolicyChecked: DUUqkICus36wegjLrpSZngPjwUUAIV2AG3e+kxrZlgOxnQs2ZXHEvjTAKEYqbJvRMSOEZ52cQ+GSTYE4/SbAxTlus6i768hyKngg8wFTJvIAx4JmTfBPYHR/sZ6551ihU5Ld7FaSghzsZlEnyCLxaiZ7Um7j8VwjKpnhY3mfxFxPoWp/v2O+3VR2+nSqap2GgC28X/O/v+WqgZ2rwO7sjwyccijylARsfV20U9tMcdJ0sA2UpUCHbH+zBMU99COq4Ldr1VL7tJNk0J4p5uCot1Y0Il847HC26SoljfpDz2RYnzcGbMr9XezUlE4J7PtxPiDiDvBIi0fS+CfXHxBp+A== X-MS-Exchange-CrossTenant-Network-Message-Id: 5bf0b33c-b9e9-4c13-910e-08ded24a7b3e X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2026 23:44:07.2102 (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: yPTc87CLUzfV+l0xJk6+YYLfWhPVLkYBzAH8zEqp9xRVu2WQIOWNaF5WHMPpbTfs36fbU2MVhmiWuWBoo/vfHEgVd09vo1LF73pzgbcbwfU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8319 X-OriginatorOrg: intel.com Hi Chenyu, On 6/23/26 11:04 PM, Chen, Yu C wrote: > On 6/24/2026 12:05 PM, Chen, Yu C wrote: >> On 6/24/2026 12:46 AM, Reinette Chatre wrote: >>> Hi Chenyu, >>> >>> On 6/23/26 4:43 AM, Chen, Yu C wrote: >>>> On 6/23/2026 2:29 PM, Chen, Yu C wrote: >>>>>>>>    From what I can tell it is tmp that is essentially returned by this function and it >>>>>>>> is the result of get_cpu_cacheinfo_id() that returns the cache ID initialized from >>>>>>>> CPUID leaf 0x4 ... the function name ("get_l3_cache_id_from_cacd()") and function comment >>>>>>>> "Resolve L3 cache ID from CACD subtable" implies differently and the way this is done >>>>>>>> makes me wonder why CACD needs to be parsed at all. >>>>>>>> >>>>>>>> resctrl already has a hotplug handler and it dynamically determines the domain ID >>>>>>>> based on the cache ID returned from get_cpu_cacheinfo_id(). If the domain ID used by the >>>>>>>> new ERDT tables can be, as it appears is done here, trusted to what Linux already >>>>>>>> treating as domain ID then why is it needed to parse CACD at all? Why not just >>>>>>>> pick the domain ID from RMDD directly and use it directly as domain ID? >>>>>>>> >>>>>>>> Later the domain ID from RMDD is just used in error messages ... never actually used >>>>>>>> as a domain ID to guide the implementation so the correlation appears to be implicit with >>>>>>>> this CACD parsing not intuitive. >>>>>>>> >>>>>>> >>>>>>> You are right that the cache ID ultimately comes from get_cpu_cacheinfo_id(), >>>>>>> not from CACD directly - the function name is misleading and should be improved. >>>>>>> >>>>>>> However, my understanding is that CACD parsing acts as the bridge between ACPI's >>>>>>> RMDD domain namespace and the kernel's L3 domain ID: CACD enumerates which CPUs >>>>>>> belong to each RMDD, and from those CPUs we derive the kernel-side L3 cache ID. >>>>>>> The specification defines an RMDD DomainID as an identifier unique within the >>>>>>> ERDT table, yet it does not guarantee that this ID matches the kernel’s cache ID >>>>>>> obtained via CPUID leaf 0x4. For this reason, we omitted the RMDD domain ID in >>>>>>> the current release. >>>>>> >>>>>> get_l3_cache_id_from_cacd() implies a straightforward query and the function >>>>>> comments supports this. At the same time the function includes what appears to be >>>>>> sanity checks but from what you say turns out to be essential enforcement of the >>>>>> RMDD to CPUID leaf 0x4 mapping. Is this correct? As sanity checks these additional >>>>>> checks are ok but as RMDD to CPUID leaf 0x4 mapping enforcement I find them inadequate >>>>>> because its correctness requires all CPUs of all domains to be online which cannot be >>>>>> guaranteed when this initialization runs. >>>>>> >>>>>> Consider for example a scenario where RMDD and CPUID do not agree on which CPUs form >>>>>> part of a domain. If only one CPU of this RMDD domain is online at the time this >>>>>> initialization is done then the mismatch will never be noticed and resctrl will just >>>>>> silently use the CPUID mapping, no? >>>>>> >>>>> >>>>> I suppose you are referring to the following scenario: >>>>> CACD says CPUs {0,1,2,3} belong to RMDD-A, and CPUID says >>>>> CPUs {0,1} share L3-X while CPUs {2,3} share L3-Y (a mismatch). >>>>> If only CPU 0 is brought online: >>>>> >>>>> get_l3_cache_id_from_cacd() iterates CACD's X2APIC list: {0,1,2,3} >>>>> CPU 1, 2, 3 are offline -> skipped >>>>> CPU 0 is online -> cache_id = get_cpu_cacheinfo_id(0) = L3-X, >>>>> all passed. >>>>> >>>>> Then later CPU2 is online, resctrl's hotplug creates domain L3-Y. >>>>> But the xarray has no entry for L3-Y, so erdt_mon_read() will return >>>>> -EIO for that domain. >>> >>> An error would at least give indication of a problem but I also see a possible >>> scenario where the data will happily be read from the wrong register. Consider the >>> following change to the scenario you present: >>> CACD: RMDD-A = {0, 2}; RMDD-B = {1, 3} >>> CPUID: L3-X = {0, 1}; L3-Y = {2, 3} >>> >>> If ACPI enumeration is done with CPUs 1, 2, and 3 offline then they are skipped. >>> CPU 0 is online -> cache_id = get_cpu_cacheinfo_id(0) = L3-X >>> >>> Later when CPU 1 comes online resctrl will consider it to be in L3-X and >>> also find an xarray entry for L3-X which will result in erdt_mon_read() to >>> read the RMID data from RMDD-A instead of RMDD-B? >>> >> >> Yes, this approach is feasible. However, I am uncertain whether RDT should >> be enabled. The underlying issue is that the firmware(BIOS) and silicon(CPUID) >> will be out of sync, leaving RDT in an unstable state. >> > > That said, there remains an open question as to whether we ought to enable > RDT on platforms where the domain information returned by firmware (BIOS) > is inconsistent with the CPUID values exposed by the silicon. I consider a mismatch between BIOS and CPUID to be a hardware bug and should never happen. If it does resctrl can complain loudly (via WARN) and not attempt to use the conflicting resources. I do not see how resctrl could "not enable RDT" in this scenario since a mismatch may only be discovered during CPU online that may only occur some time after resctrl is mounted. On 6/23/26 9:05 PM, Chen, Yu C wrote: ... > > Thanks for the detailed feedback. If I understand correctly, separating > ACPI enumeration from CPUID enumeration would look something like the following. > Could you let me know if this approach is feasible? > > ---------- > 1. At ACPI parse time , record the full CPU mask from CACD for each > RMDD domain without checking online state or resolving L3 cache IDs. ack. > Store a per-CPU pointer (erdt_cpu_domain[cpu]) for O(1) lookup. Why is such optimization needed? From what I can tell this pointer is only accessed *once*. I do not think onlining a CPU is a hot path? Could this be simplified to just be a list of ERDT domains? > 2. At CPU online time (resctrl_arch_online_cpu), validate that the CPU's > CPUID-derived L3 ID is consistent with other CPUs in the same RMDD: > - First online CPU in an RMDD establishes the L3 ID for that domain > and inserts the domain into erdt_domain_xa keyed by L3 cache ID. > - Subsequent CPUs must match. On mismatch, the CPU is refused from resctrl. Considering that this now establishes 1:1 between RMDD and resctrl domain and that resctrl already maintains a list of domains, could the x86 arch specific monitoring domain (struct rdt_hw_l3_mon_domain) perhaps just point to the ERDT monitoring data for that domain instead of maintaining a separate array of domains? So, when x86 is requested to read monitoring data for a domain there would be no need to query an array for the ERDT domain info since the containing structure already has a pointer to it. This may need more care to organize the ERDT per-domain monitoring data structure when considering the references to upcoming additions that are not clear to me at this time. > > 3. erdt_mon_read() looks up erdt_domain_xa by hdr->id (L3 cache ID) as before, > but the xarray is now populated lazily at CPU online time. I do not see the need for an xarray. As new domains are created during CPU online their initialization can just point to the needed data, no? Reinette