From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 9FBD3145B11 for ; Wed, 24 Jun 2026 04:05:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.10 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782273950; cv=fail; b=lotAXOidE/IVNKRdpb3u0vyjyKoMvKl5Ot/UtXjOzyIXX9BjMhYmSb6Z62T78mVkei9mMPbESG0YMbFPvtYdQ4CsF5ZnPxFvozgfaGl1gGBPhIOFY/9klOEl4xsiANfmE+KxJHWFQ0r+X5fgsbTwuUgq1KpEM/2Gz2pNv3M87Ew= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782273950; c=relaxed/simple; bh=OUKtNOjSzhHcqvqgKZoy7wZqpYK00Zx1662n6liFIZA=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=goG+0xMeVHNg2vmrhZdH2aTtouWZS3E43GGZEzEl6ypnT5iWXVVSHABpELNdREujC0iof+yEGSPdvTD9KGNhhMNrzxhQfN6TbFzo4Rx4UsQLYT97FmjPJE9H6W+/LZaEX8lxLqV9dzgN0uLtknJRX6Ml3/t5z74hCult+/qorn0= 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=KnQ1mmle; arc=fail smtp.client-ip=192.198.163.10 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="KnQ1mmle" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782273948; x=1813809948; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=OUKtNOjSzhHcqvqgKZoy7wZqpYK00Zx1662n6liFIZA=; b=KnQ1mmleIF1G0YiuifPXlyeXEJaQVfAT1fsTEZFZPz+5Hc25gEjcZhVh BrCSdamoukw8WPOCAi6ljyDZStRw6xfM6bQzoQwXIjOOYkCwuPWEJO7H6 mnNBGFN1p2648hambkxemYC2ZJctHgCWEmm/NwqjnOLkX1YjmktbMt+mj uBWGyFCuYmGIdp1MfArlqcKYv09jejN0KJps9vENnSyJ9zYSPKSjdN9Ne AbBsZO8LyHl54GZC+c451/Ul9C9RPxd+Kp4C3QHFYhhUBxp3K3HngMmZ7 KyY10Ly1pPfR8BC8zJRzQJ0p5qWYj/immozonRKjKELQOOkJ3Olql1Aqo w==; X-CSE-ConnectionGUID: bpGaGPovQmOZ8pPFREduXA== X-CSE-MsgGUID: Xvm6y+KLQ4aZVpVrADWV/A== X-IronPort-AV: E=McAfee;i="6800,10657,11826"; a="94417415" X-IronPort-AV: E=Sophos;i="6.24,221,1774335600"; d="scan'208";a="94417415" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 21:05:43 -0700 X-CSE-ConnectionGUID: sWArE7b2T5eh2EhTuPXbrA== X-CSE-MsgGUID: KjBg3XzjTUGDJconOR7O0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,221,1774335600"; d="scan'208";a="279867898" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 21:05:40 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) 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.37; Tue, 23 Jun 2026 21:05:38 -0700 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) 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.37 via Frontend Transport; Tue, 23 Jun 2026 21:05:38 -0700 Received: from SJ2PR03CU001.outbound.protection.outlook.com (52.101.43.20) by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Tue, 23 Jun 2026 21:05:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=asckOHlFeuFCuWR+HqiVcfvL/qtulrgjVnbgUqRcebENJDMnOocqYNrAn9cavb2Z/D5foo2a2wxWWNYlQizKJy0F6zGgzYt23JS9rr3XXlrAjLWSLZor/Hjz9gNT+NMtuoTjOYCQWAqRgSczIIchMPMD0GKU8tnGDVJvlavta7qXDYq4hN5/pbHiLw6284st8PEtCwuRwx7ASEHQoRTU6lNS88RL3voDmPEjmFIgDITN/lKwN61LHpnBbIqG3DaQyYTA9ChGVJ2PcxqlgbXHAUPxuC33NN8a/yrnidbxBbv5ka6OnmPXFYP9BSEZDzxQZJuiH6Qjkgk6vRK+B5mj0Q== 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=jg+h9XChmhnOYpYUWGqkk/n6m4VdhMEOUStb00+Sk/w=; b=a426OrBTt08EoTvzPSPHZL5XeOVw+2T5lj2i93lDiAYXrPSDIWcg3CoelyTTtlrsMSS9ro9YLU+L/q4m24kwUckgvSmWKaksUqHcrrZUzzDTr/Llsrc7G2DJIYjJ7OsR7fUfUj2su+4YcjaixSO/ar5Xo5nhwVwY1jJuB8r9yLBb/+a/zSUZf4G+IovMIKIwVaSED9xVU5tuwYdmEUDPnSiKJbRAVTVtdjvX4oG51ohpvVxizIrlQtG2zOIOZgt7vpOroEJEei72Mm7qV5SmrvIzQWRGJm53vykUuShz6uqXo9aRIchrxu3I9+6T6UJusHLfExV2/n4O1fa+GyY3Pg== 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 PH8PR11MB8257.namprd11.prod.outlook.com (2603:10b6:510:1c0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.159.12; Wed, 24 Jun 2026 04:05:30 +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.0159.012; Wed, 24 Jun 2026 04:05:29 +0000 Message-ID: <4b48ec4d-517d-44d0-8be0-7e24d0970b7b@intel.com> Date: Wed, 24 Jun 2026 12:05:20 +0800 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: Reinette Chatre CC: , , , , , , , , , , , , , Chen Yu , References: <807a91c2b6235f85e2d19d4293c17e53a8cc69b2.1781332698.git.yu.c.chen@intel.com> <288153df-307a-40e3-96e1-ff4ae8f6bc5a@intel.com> <2835922f-d2b7-45dc-92e3-c6aed4e79fe9@intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2PR04CA0017.apcprd04.prod.outlook.com (2603:1096:4:197::15) 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_|PH8PR11MB8257:EE_ X-MS-Office365-Filtering-Correlation-Id: 295d9445-b297-4fdd-1215-08ded1a5d443 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|376014|23010399003|7416014|1800799024|366016|18002099003|6133799003|22082099003|3023799007|56012099006|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: mTap3rcnWosHX7PjKiND+2d8wopfxhnZ3GTsJbMUX+P9cAFRK7bFe+j5bSJOUHa2hTS828sW8CVbzy+5DIFII69NR8It8QilCa5KNeM3pl1Ni79MyvLNk07Pm0+st1ctRJ74mOCYHCjOZnvKAIzMUREEwgFFsowz2K4N4Az80YCbDD96V1PcVQL558L+eCoIIMbK7ljf/gzj+2Ryx7GaCKfI6s7sS3evUBL1Wrbn8SCqkbg06J5N9fOCynNpZfce+nTkK+wgFNl6jb9JQYw5xzww8MnDuOY9KHVK/n8RmOI+YggPWOUiTvrq57mMiga6wiOPsU7kZC4V+zBz/Ox6r4L5BcP9nvV1p/E8fH908zTo++SUV23FVnv/lBvQ8+pmFgLK7gkR2FXVlYnejmn/fNGl0QUSE31GKwat3BuetcWsQjklRmUE3+1z3NK7xOaz5J9t2zPVgQAJ3In1g83BgFWe5EiBCqxmOLNjQJMk44uXxWYF6hq7a+x0YcK5/c7TnEOgsdiH+VREZp5qOmh+/0yn9M8+cIoj2oH9JcmoMcayfoNYsdjpIfVYr2dhD/wZeQbO8HIppQVLgaW3nxsoFrX5A7Z6ui8ebmJX0T+fLtZ8vVBVn8/BDRbbS+lU+7Sbpa6lJZaOssXbSsOY/RP6QwZqVNgye7EirCJklvkFEic= 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)(376014)(23010399003)(7416014)(1800799024)(366016)(18002099003)(6133799003)(22082099003)(3023799007)(56012099006)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M3JaQ2lFVUc1WndXU2JaMGRnTyttWXZnSnowSFFNOXErSVh4dW1sSW9YNm5B?= =?utf-8?B?WmZ1b001TWtMOUF6UTJWZTZrekN3TGtTeHpaWTM4b1hVS0RlVVBwUkg4MTVN?= =?utf-8?B?VVZKWjM0QVdXWTZkMVFQSGE1Sk04c3RhL3hGbFUwYW92YUNIOEFKRVFwMHFx?= =?utf-8?B?VUVvY1BsRmVUMWlQZGoydUhqOS9DVmN2OTkrTVZmYWhwb3l3c1Z6TnRjMVkz?= =?utf-8?B?djE3Uzk2REJ1dTd6dWhFSm1aUFFnTzQzNDhpSzVLclJVWWl6d0JqM0pIcU41?= =?utf-8?B?WHpMenQzaDdrUzlUbmRzM256bklMdzZlN2NTaERHaEtqRThjVUg4b25xN3ZL?= =?utf-8?B?WCtyRWFkOXBPSklEQVNzelJkdURSK0Juc0lSS0M1bDAwc3JHa0piSzFoNzhJ?= =?utf-8?B?b2pZWFh0MmpLdWxKWG01MWFUVitQL2g3YlNTNi9yd0tRbHdFcnhCYXFZOTRx?= =?utf-8?B?NmNFSkFXZENwbzB3MjN3QnJQRmltQXY3elEvc0tGUmNiUlY2NldocGF2ZEls?= =?utf-8?B?Uk9BenNMeUptaU0wLzZXa1YrWFI2eU9wTWtuYWVUamhlcFlyNTlZMEg1cSt0?= =?utf-8?B?SE15aEZzWkZYZXZndjlWMVAyQXBwbmYvM1FZNFZ5eUlVVlJtY0NVU2VYMHlY?= =?utf-8?B?Z1dBRlpnZXEyeXNLZlhPYW5sa1Z4S3FJNTkrd3R1cnEvdnRRbm5DYUVyRkJK?= =?utf-8?B?RGdpYnE0N0U4Tm5tVkFqNW0wRllTK0xVeVdmQ1ByMFIxcnFITVVFWGRzdlBz?= =?utf-8?B?QVlRZUJIVXRUZ2ZyYStkUnlLTGtoRkl4bGZ0VU82bjhWckRKNXdYNmFueFdy?= =?utf-8?B?WnUrTy9OOTdQbUZiWHV1T0NaM00zWUhtZ2dwaEplVHBna05ia0tMT0JmQSta?= =?utf-8?B?cTBmQnVVU0xDOXdad1lQYjV3S3lLVnlpTkh2MVpCcC92RW5hNCtyUG9HcFNK?= =?utf-8?B?Q0NSaTBUNmEzTjI5T2ttZnFBRWdobDBIZExKbC9yNWZwYVQyYmFXbDVPc1NZ?= =?utf-8?B?a3kxL3VOcExraU9iOVZabjdzV0pKMFNWYUpEYVNCbGlJZXN3QWxOODRuN2dX?= =?utf-8?B?amZscFRacTVSMGtMMlZDbnBmekxRVkxqYWZpZE91Rzg1aG1WQTZJbUx6Z2Fj?= =?utf-8?B?TWpIRFlwQlJZU3oxeTRqcEE3NSszemh0TS85RnJCWEhxYnpwZ1F5ODE4T2or?= =?utf-8?B?YUJLZ0lPNGVzSUFPTU1pdzUyZHRqTEx3a3lXMkp3d1RNS3N0S2RDY3hMUnAw?= =?utf-8?B?QUdBdndITVptM3VYYmcxQUc0aXFzV2orQUx1cFhBMVdURDNYNVREZFMvcm5O?= =?utf-8?B?bjJqN2FtTURpeEFvdkNScXZTZ2hLcnd0aWwvMGlTcnd5d0RhNGF3NDczUnJY?= =?utf-8?B?ajVwdUFMejBoVUlzdG5rV2hDWWk1WnFrM3p1Zk94Z0dUbmhuSjFGalRkK0li?= =?utf-8?B?eUVVOGJxUWlDYm0rdXQzV1krVHdGUUF5QW9keko3V0Rab0ZkS0dMcTR3RVBu?= =?utf-8?B?WEtJV0Q3dWZFUW9CM05xOUFtUHBsa2ZJQXhzb0NNc1EwYkVURWdYbHA3U01a?= =?utf-8?B?blNHRmVrb1JDd1JDMW9HOTd6YisxY3BHVktNeDB2L2hnc3F1dXRGTU1jTmtu?= =?utf-8?B?NTZNRURaWS9FcTl1dTd0eExlOUluRnhXRnk0SVBTK0IvNVlPL3diaXdLZkR4?= =?utf-8?B?eWpmMUtlcWY0S1hGbUJacXlrYjI0VEJpUkVFZU5ZQWFPTjZlblZMZjRoNWRs?= =?utf-8?B?SnpCVk5DUHk3RlVoK2Z0RnpCaUhtd1IyYmJpcUpOWHdvdVp2NmNOcWgzVERm?= =?utf-8?B?TFJOb1lBb0hkdkJMeHphclFmdWlTN1ZrdGtNWENSZFIvZlkvbUNWQU0wdDRG?= =?utf-8?B?ZllrVm4yTEpGcmQ5STlySWFzV1M4VXUyY0oweTFHSzNvMDVtOXF4TWluZmZV?= =?utf-8?B?QWlJWnhVTDZ4b2RCaXA1OHRQNDRUaGpPT0xnOVh2dGF5cmV0N05mdnhMVEQ1?= =?utf-8?B?VnJDa2NYSFlQUXoxQ2FHVWJCZEVJcndNMEJ6dTRCUDRvUHJhSTRiSk1PZFZD?= =?utf-8?B?Rmx4eVAwUW5DZ1d3bThzeTZpRGJUZkoxakJhZEZpVmxVcDlLOU1Wbyt5b1FN?= =?utf-8?B?Ym5ycjBNeXVOS3V2dEhSdWN6SkFlVU5VREVGZ0N4RUdsc2JwakFvV2RZTzhN?= =?utf-8?B?VTVzb1BWaUJsdUE1K2ZlSFgwdnhZcE9GZUEzS25HeWRTRlJnNWdFbTBPZmtZ?= =?utf-8?B?R3JUaTdmSkVkeGRRUnJtdmdDeXlNZnZLMXIrcmNhS3JHZnVLK0gvZUxLQnBk?= =?utf-8?B?R2k1azFFTWs5c3dFT21yc1ZUcVBVUG5tb291QjVHNm5RcVM2NUhUUT09?= X-Exchange-RoutingPolicyChecked: LCcQmyLgmTh22b37gOCg02LpE0dh982nBVFj7TxWilOSp3llziMXtMZc32HZxEFwMK9I9m9pHAFhKDNmj9zs1h4/Z5YxD4oHme82Vu4XGTjvBzaVBaTHk1MTgOoMZ4/87W67r+eYdOpNn1siLGvgBp1SWIonl4OkpXIZEGZe5GxMSAgW0OCgo8KHU+f4cnRG2+5H0CJC3qb2XoqyQmoYxPaVIBE8GRaN+PbDbLw6E19f0iC1OTLiSMjm571nhZnyyBZc172lzEeFPZUBZbWeBLyDkIMEAwNZFlsrPSVlV1T4HIajZU3ZJjqwm4LKM4/HDFM8c/5OVip1urdD3FKPug== X-MS-Exchange-CrossTenant-Network-Message-Id: 295d9445-b297-4fdd-1215-08ded1a5d443 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2026 04:05:29.7504 (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: 7WyxtghAZ3Zhy45hEdRto9yuCg3HydvZMU/G8aYc2Y4lGjHBa/dMdHn4nO6OK2WUf2+yqyV3ZBxeNxsf7WpvaA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB8257 X-OriginatorOrg: intel.com 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. >>> >>> If this is the case, I wonder if we could run the sanity check during >>> CPU hotplug to reparse the CACD table whenever a CPU comes online. My >>> thought would be to call get_l3_cache_id_from_cacd() within >>> resctrl_arch_online_cpu(). >>> >> >> In fact, parsing the CACD table during CPU hotplug may not be feasible, >> as the ACPI tables could have already been released. We could instead >> perform the check directly against the erdt_domain_xa xarray. If a >> mismatch is detected, disable ERDT and fall back to legacy MSR-based >> access: >> >> /* Called from resctrl_arch_online_cpu() */ >> void erdt_verify_cpu_domain(int cpu) >> { >>     int cache_id; >> >>     if (!__erdt_enabled) >>         return; >> >>     cache_id = get_cpu_cacheinfo_id(cpu, RESCTRL_L3_CACHE); >>     if (cache_id < 0) >>         return; >> >>     if (!xa_load(&erdt_domain_xa, cache_id)) { >>         pr_warn(FW_BUG "CPU%d L3 domain %d not described by ERDT, disabling ERDT\n", >>                cpu, cache_id); >>         __erdt_enabled = false; >>     } >> } > When considering the example scenario above I do not believe that this implements a > robust transition from ACPI to CPUID. > > Additionally, disabling ERDT during a CPU online has broader implications: if ERDT was > enabled earlier then the associated events will be enabled at this point and have > mov_evt::any_cpu set. From what I can tell this would just implicitly expect that the > events could still be read via MSR but not actually route the read to the correct CPU? > > I think it would be simpler to separate the ACPI enumeration from the CPUID enumeration > instead of wedging in these snippets at various touch points. The ACPI enumeration could, > for example, just record the ERDT RMDD domain <-> cpu_mask mapping without taking online CPUs > into account. Depending on which tables are found in ACPI, if ERDT is the intended mechanism then > any duplicate CPUID enumeration should be avoided. This means that there will be two unique > flows to enabling resctrl events, one for ACPI and one for CPUID. The x86 online handler can > perform the sanity check when a CPU comes online and since RMDD and CPUID are expected to > correlate the CPU could not be added to resctrl if it is not in the expected domain. To me > this seems simpler and more robust. > 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. Store a per-CPU pointer (erdt_cpu_domain[cpu]) for O(1) lookup. 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. 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. Pseudocode: /* ACPI parse time: store full CPU mask, no online check */ cacd_record_cpus(cacd, domain_info): for each x2apic_id in cacd: cpu = topo_lookup_cpuid(x2apic_id) cpumask_set_cpu(cpu, domain_info->cpu_mask) erdt_cpu_domain[cpu] = domain_info domain_info->l3_id = -1 /* unknown until first CPU comes online */ /* CPU online time via resctrl_arch_online_cpu(): * validate and establish real L3 mapping */ erdt_verify_cpu_domain(cpu): dom = erdt_cpu_domain[cpu] if (!dom) return -EINVAL /* CPU not in any ERDT domain */ cpuid_l3_id = get_cpu_cacheinfo_id(cpu) if (dom->l3_id == -1) { dom->l3_id = cpuid_l3_id xa_store(&erdt_domain_xa, cpuid_l3_id, dom) } else if (dom->l3_id != cpuid_l3_id) { return -EINVAL /* mismatch: refuse CPU */ } return 0 thanks, Chenyu