From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 51D9C3845C1 for ; Wed, 24 Jun 2026 06:04:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782281061; cv=fail; b=G2620szZ9Lht1ANvup3QBOjgi2xsIuxOunN+3JLvVLRisLViu2nVUs2wIGS6jNI1V8fF1xD0kTjJLMrCWUQKRL330A+TgEAxe7pJiERfYHgcr42UpZlPMFqGc82fYHw9bKksWmKyXGbhUAlaYp8kd/E4oC36wAS/w8QWKzuJNAI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782281061; c=relaxed/simple; bh=SqcMNOhPlKe0LZCCI6WENxrJ3QdUwcoociS+Ji5hIwQ=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=Lx80YoYsxAfxwHPfdUAZwnsIhSuMBPAEKUwcG810Ha0Jy1Wip0BagydmplCYwo31KGDfH5NbWCYrHB70jXAinBIAfrxeAv/RLWU9RwJ5+mhD7bMuPLiWng1nlPgZV/0AaMbozcFiH6xDw7VWauhaHLjZBT75YiRNDDbmWt4TnLA= 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=kUZy/7Zv; arc=fail smtp.client-ip=192.198.163.18 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="kUZy/7Zv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782281057; x=1813817057; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=SqcMNOhPlKe0LZCCI6WENxrJ3QdUwcoociS+Ji5hIwQ=; b=kUZy/7Zv+OL+b95v5RU3NXjFwv93CO6OKHwDdqRg1QzHaYl4UsPHjEdi rcGZw7D6QREIq+PAmSa86pgPGq6uXx+pIyeU/9GyJpw7+S1ZyHT/Oi7qj f5pxVlQwd5FhSQFq1AX1XzUjPtI30Zl9jSIkJ+/uPdEV1/tsHqcpNu9NZ iOW0fnyu1iNGK25F/+RUw9ejh4sr90HgaEmuXwHeWZo9yHKycr+7Ba4Gj HZztH0lVCD0SRex7urcncynouHhtYzDip/ShC34t6Zbg10OcrjGS36Bg5 FPn7F+PJsTtCKYew/ayxfEyvWf2ac2ljJ/2ZFQCrKoMrtoTrEdrGcn4UP Q==; X-CSE-ConnectionGUID: UOCGyqCYT/iwk42On0N+7g== X-CSE-MsgGUID: dggZCTBjQLmyfNpdl2mPFQ== X-IronPort-AV: E=McAfee;i="6800,10657,11826"; a="82148823" X-IronPort-AV: E=Sophos;i="6.24,221,1774335600"; d="scan'208";a="82148823" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 23:04:16 -0700 X-CSE-ConnectionGUID: QgziasqaTc+kVh3r0JFsog== X-CSE-MsgGUID: UgkndknmQ1mvi1uKE5SVBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,221,1774335600"; d="scan'208";a="245606080" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 23:04:13 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX901.amr.corp.intel.com (10.22.229.23) 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 23:04:12 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX901.amr.corp.intel.com (10.22.229.23) 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 23:04:12 -0700 Received: from DM5PR21CU001.outbound.protection.outlook.com (52.101.62.27) by edgegateway.intel.com (134.134.137.113) 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 23:04:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IBhBi2hdYQHu7Ma07Cd/hwFz/R7EAxBuJuxJitjDoDzupItpv79sfUt2w8ftX1iWVB08eZUBBoGKk+LxmLwkja674RwVkYjQK9J6VuO6Z6ABUrVq1ovtiFr+apLEbkfPiMUM0NZ3XLYkAOo1Q+qEQZpTruwU2sYkgDZWiYxEEDQPcmRI0bDLH4Ht+3jNt33vQm25eejybnsFuOpHccp1Gpwv4hw7HGFF+k2uYhHgnKCDsb/6JCYHEg76As2unsfzP1vE86mLqq+X4Kq2hmwTRvns3kp9Wb/OUoeeo2IuS/GCjjuwCdIJWsmPdYZOsW0rRYhBYsfSpfmmKDmsfz60VQ== 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=xVLZlfqUh2maBwqDIs/z37U8d6bkDliZln2MMQ+9nFw=; b=rrvd9cwP7QTIjYgHmmf7dLWxuui45LDG+9jLfCXzYSSV7yMucIz1ghNbbNJgDVkIJrrbduqfeTuru36nyXOWXshGbRw983OUO9rFOcj1HII4zFgRHzuDTXpdfZAnlgdUCdVb9j63lT4slYx5csdNhqOpqZaC5j775UgW48/LXsjTw5uq6OEDq0NVHx2ia+0UD/sgv5yPnB8dirOcw/ON/tVci1uftAE9zh/XR/6tZ+l8ifj+VdAxOipTtzAIAOwLR0UgkxO4SBcvb4taNZP7JKo7RMQ8LMOCIvwnoLDCt0h3EwWu4nruSLPwgtjY8f9hscFqClD0BF50iRqe2M1xEA== 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 CH9PR11MB9902.namprd11.prod.outlook.com (2603:10b6:610:345::18) 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 06:04:10 +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 06:04:10 +0000 Message-ID: <1c671ba2-501d-4b31-bd33-9cb23b54db01@intel.com> Date: Wed, 24 Jun 2026 14:04:00 +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 , Chen Yu 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> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <4b48ec4d-517d-44d0-8be0-7e24d0970b7b@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TPYP295CA0023.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:a::7) 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_|CH9PR11MB9902:EE_ X-MS-Office365-Filtering-Correlation-Id: ddc9f548-30ae-4704-ccc8-08ded1b6684e 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|1800799024|376014|7416014|23010399003|366016|6133799003|56012099006|3023799007|18002099003|22082099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: oMD3JAsomwlXpPm7AASOtC2AG3Bl/lRUDU6Z/XkyExfrKstPOQ2gP7xdnPL8eJ8yjzyVePRA607QBR+a+SA4fJK1fWKm1bkczOFjZB9NSQYsMIjCIwwxHIapzyAnF1kM/J9bqQB+x2wVJBhYRN3SzsogLIDZAb26h5EpJsX9W+w91/+oVc/JOg2ItOW0T3f9autKrNVCBpWq49XN+/31BTqGYoMQR5FxM5U87UphUhnypDYPnH8m4/nOnhdcdB+x7p8shdZiRxj9NViSoeBh5BNZ7FCujpNhuSL4l2QKc8ylndgth0QtQSgGwVNszNpt+m5/k8aRTzX3+Tj4LqW2pvhflqqQKK/WtQ4CPU+6SeSkGBvB8Kygr7uqDpDRzp/x+yfsHZHq1K+cFTrHY9eBdiNLLTd4kB8MmzqxmUNLQ1/RMOdKWt1uhNuv5PrFgE1QhKHxwOemeThruuDMeEE+V6YIFoMHUeLdSbGbT952h8WJ9sVhfgNCIvGgGiFQsjZp3sRqglPDtCYNqUPgSP8IA6HoyC4bzzu0Cqm3bRuZk8dRE4cxMhRZkIsuW2rSovWc/YlJYaIlYLWmxm5uPrABrrD9nO5nE/2Ns547yc7sDqTkTtzL5yZTyakFex88I/ERYEgZl3hskKk9JicGO30g2s5IcBYwqVIXP9aJrQSTDmA= 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)(1800799024)(376014)(7416014)(23010399003)(366016)(6133799003)(56012099006)(3023799007)(18002099003)(22082099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UklnK3prZjNFa29NaUVCM2lCVkQzWkEzY1VJdDY3cXFVTkJtbmtjeEhXRVZT?= =?utf-8?B?YUhnM0ExM1lpdktoSHlnVnNvNXdzTzNHaDdvZG5aUHVEZjZueldnOElBZG1O?= =?utf-8?B?c1U5cCtQaUVRNWY4WHdIZzlldXZvbTFvcUxaWjlJYjBzZ0lNdkMrVlNuMVln?= =?utf-8?B?Y0VpMzJKcVVwbFlYMEFsdVhNbmJOYk03RTRZdTlSRmh4WTgwR3ZleXR2N1Js?= =?utf-8?B?dFkzMUhNU2pHNm1UN2VNMEpUSitMTXhQb1pLbzhXUWlxRnVHSFc5TU4zSjFL?= =?utf-8?B?S2hTeWljRmxXaE04RndwZkFsRXpqNk9ya016VDkxM2dWRmtmYWJ2ZENiNHZL?= =?utf-8?B?NElTN0ZCTlFaZGhhaFhrbk5NRUs4NXBlVXR4YXhvcHBnbGt3R1orMnJaaUpS?= =?utf-8?B?aC81bHlYRUNObnF0c1FKTzhjUksvWG8wUTM0eG5weVA0VUgyQWcvYzNhS3oy?= =?utf-8?B?M2Z2eGpRQVB2OHdyellQYVBFbmE5WVUyVlp5R01JMXhvTGR1M2RVRHJvNmk4?= =?utf-8?B?VU9ONUJLckZob242ZVhmbzM2OFlVUXdDeEZ0czFtY2RCbndQc2FmMFhpU3JN?= =?utf-8?B?NzVUNGU2SlpxeUJhOHZKZVZSN0U2NVR4SlVJcXFkUmo4QXFOc05MMWZmdG9k?= =?utf-8?B?MnpWVEZZSzNaZzhlL0p0LzBlNTY1WHI4cG5rZzhxRmt2eGdFTkJCQkFYNnNF?= =?utf-8?B?dnNRb0xTOXlvejd1SG53SlM2TmI0alBNYUl4cGFxalhwZWMzcXp0VndKb2lt?= =?utf-8?B?TW84NXZVWk5PdXh6dmFXSEJaa3Evb0hERGJtYzBBNEhsbWJpUjBaVHN0Rnpl?= =?utf-8?B?RWFseWk5SU4vclVuQkUweTZkUnBPVTBMTm1XN3N5d0hRb1IzVUllMUlaa1Qv?= =?utf-8?B?SzNYdmtFalhzenhZZUZhMkZyNWwrR3dRRzMyaFByc3U5cDFuVTZxS1czSGpm?= =?utf-8?B?QTlJTVBDWUxQZTRXa0lDUVhRaWViaEtSakdKVXpOZzJJa3RWREFNTWVFZFBu?= =?utf-8?B?R0pEOHp6b3ZJWjJBUnJHNU8rTUxXZHZ2YTR0OXdiM3hqdDlzSHJPOVFQcUdV?= =?utf-8?B?M2doTWd3YVFOYXR6SWRqSDNPaEloRWVvSmw2Y2M3N0MzOHZpMnBsSHRhQzQr?= =?utf-8?B?cEhhd0NGZXhLYXNBdDJ1YW84c1pBYXgwSDRweHQrR0hRUVgzQlZqaXJLTFNK?= =?utf-8?B?a0J2c2YvUVA4Rm1RV3lhYU8zZ1cyeGZOdzlQdVRvZzgreThqU3lCYjcvN3l0?= =?utf-8?B?Tzc2MmtqREFKcCsvVjd1OS85aHk0YWJ1Nlo0cWcydUxLQ0xVTDF5azF4WklM?= =?utf-8?B?aVVLWHNVV3dWckhnQ0hpSXBnQlZVaGo5cXRyWEd4aW9MRjVqZ2JUYUQ0RWdS?= =?utf-8?B?NmI5aGl4VUZoWGtaMkw5YnU0eHZNRlNkVFZhVUFFeEpTZnlOWUV3WDNFeVVR?= =?utf-8?B?RVdKakIwWHB5VUxYckdGd2U2TUdMQzB6WEZOblJJSHo0T1Q0MGFab1I2MXJj?= =?utf-8?B?bndLQm5qdkI3dHZXTTk5MmloV2FQSmZzTVhjWXdGaTYySjFqbUk0clR3NG1u?= =?utf-8?B?Mi9NcDR5dlY1a1BJbk9OT1dnQndwSEg4dFBka29wTW1acnFqNUMyMmFTSkc5?= =?utf-8?B?cGJzYmhodVVLcVVwM0dhOGFuY3M3d2lBbE9RbG9vOTc2NHhudTFaNEY3ZUVz?= =?utf-8?B?Wk1LcndscXd1Sk1QMkxuajJFcUJib2d3MXUwaWs1VURVS1AzWGpoOHcxZXc0?= =?utf-8?B?MnhyeUVaYkdEenNzaGIyUlRNaFYxM2pRT3V4MHdsRXNkWUQrZHduTUVwOTE1?= =?utf-8?B?T3p0bmRGWU9TNGlwczE1bkZyaXMxSGVSVUhQY1E4TkVIZWQ2NG43N1VpU3Ri?= =?utf-8?B?UFlOVklJdDFhOWJIZ3YyZWErZ1kvcVRZVmhycVNYcStNeHpQaCtUWVE1ME9p?= =?utf-8?B?OVZCdUdXeDh6eUIxbzBudGJWTnFvSEs0Rmd4cHRyazllQ0gzWmhHZDFicEV0?= =?utf-8?B?azN4OHZmNlU2Ulh5TFNHQ1JPL01iQXd4ckFqbzMvU0ZaNWozSGs2Ris5SnRi?= =?utf-8?B?L1JwUFAxQmdBcHpydVdtelFRVExWZnRuVlZ3QllhdDdtTWM5VFNmZGE2WEx0?= =?utf-8?B?K21pMnZKcXVjeDZrUmlQMDRpYWIxRzBOQXdXSDVYc055TWdwaWhaYmppdjVh?= =?utf-8?B?VjlZRStnYTB3MUZGamlueVVlNW40ZFdvYTd0aUdFR0JGNkQvcUNwVnpyMC9Q?= =?utf-8?B?L0g3RWkzdWJLNy9IZ0tmV0pkRkZUbi9LSnVyQ3lTS3JZb2dpQkJPVjA2QytZ?= =?utf-8?B?ZXU5Y3RySk9kMmdCL0FxbVNKMkFRaHh6UmRuK044VWZUblliSTNLUT09?= X-Exchange-RoutingPolicyChecked: mpekkMCCPzJeY2PzKV0JF//t6CKjLrFtmCfXL10jiITPpGgezzG2LtS2HYdST5P8wy8ALr15om6oxSnHBNEaqhHnkXVOau7KskT3uAukqVwJ0MUsRsRC5I1VErjXpeiCVFfJB6kucEjvcdx4EOJgxpzGnoUGMADaDxdTdDBvB01MS6sodyYBa2nZ/03J+x3wr806pRzeA5fn0qAOn9gqXrFwy2eYekDgNuNdWB/naXNyDxK1VU+LAqVAKDDz2AmBy7RIyexsCkb2ns9BoQ56wlRlRpQwpqAgTtF6Fma0fue+bfClANCE7tjdfbAm0c4HfOdSIovpe7lO+x9WmX/ndQ== X-MS-Exchange-CrossTenant-Network-Message-Id: ddc9f548-30ae-4704-ccc8-08ded1b6684e X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2026 06:04:10.0819 (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: +3lhZdNLH5JB7kKLRVYvxYm4AEljah+j7obEc/HIHXQulMHlvIz86ZLrErQoKAmcgxVlwEqwonSPHtb7WmJhEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH9PR11MB9902 X-OriginatorOrg: intel.com 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. thanks, Chenyu