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 4E8C230F526 for ; Tue, 23 Jun 2026 06:29:29 +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=1782196171; cv=fail; b=bnC3ko+Uj6zzau6ViVJVpersM329yQLlIlJeIucoU3lz+0KWYJKu7UAIW4G394G31DuG3qFXuX6prI52SDAuusJcOlncxUj1Fcjwx9P1X2j3IVxL3ct2dv7AwPUCqCK38Qn/ymorCViBo3caOdqHN/ZN8GCed0XIRVhaDL0/QgI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782196171; c=relaxed/simple; bh=sDLT9qnEFS6m9XD+5tqdO7PWBdXW1Q5+JjwSt7rlAyE=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=RtyUhAbPwwOihhpX1Q2XlxB2s4hn70iru7OSKRnY8lBZ34krEk0RpsRNMnNP4XL4JEWAhawB8fbDgvxF4O6tvfrzyBzkxTJc/tgP27z8XidoYxF+n7hIFCdrQTkczzaoXXdYszcAel7w9Im9dv/kACWSXOxn8e1MRuUwIv1kJRQ= 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=W+m+vtNY; 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="W+m+vtNY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782196169; x=1813732169; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=sDLT9qnEFS6m9XD+5tqdO7PWBdXW1Q5+JjwSt7rlAyE=; b=W+m+vtNYM7APBF/zLi1G+TQJrRQTaCaib9+3R+Ni/YjxfmEQjmFI5nLP I8Kpz9JItF2Nr0yKYtkofF+ImWI5IeM3DWYjf8nSu4zsea4wybxhP+Cn5 phHAJ5eccHxFjDUDUMy1Fq/tcAond+ic+SARF2A3+jlhPnf89yg6jYeLx y9u6j+3Y2cAO6y5+P2/UpHwSCWvgdVOo/V8sKS6XzRnuDAJC7hSO9347X oOoPpMtGI4cxvFbuBholEFCGBTskYYju8eifriWwHJ97U0NKNQ0iFRgWB Yb+kk0DzJoilZSyeTp7ThFihwPZYNlH3UY2Ct5T8k6AHrFUpdaW1xBH4c Q==; X-CSE-ConnectionGUID: we3FF6A/R8uqpEjDZjhfRg== X-CSE-MsgGUID: 3feAWezaSe2MNtbuj7gFGQ== X-IronPort-AV: E=McAfee;i="6800,10657,11825"; a="86618708" X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="86618708" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 23:29:28 -0700 X-CSE-ConnectionGUID: mUVqRszBSXim1ed9gcotPA== X-CSE-MsgGUID: lavo2v5DQkeP/sAEuAV2+g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="279610312" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 23:29:29 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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; Mon, 22 Jun 2026 23:29:28 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) 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 via Frontend Transport; Mon, 22 Jun 2026 23:29:28 -0700 Received: from CO1PR03CU002.outbound.protection.outlook.com (52.101.46.55) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 22 Jun 2026 23:29:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IVjHQUikIv2WSs/ugnq9ODV4pz/TXuqRXVpcz73LBcUxIl6ulgY6+E6ESbLcpH6vaughhjVbFa2nixfdtyg0/iDuV7p5VfQ+rFv/6SRcUpvPBjRiGmwq/KCAPXj1n6Z3LpT0Q/7LehkqxACkwRGr1nr86RsBsxf8b9S66Q5WNxWJdyRzGPmHfkU/I9tLfpJjOmUwlLfuVP0NeKpRKWOE0KirWLfgWcu+vIIKz1Ix4MNTxTw5eNzZtC8l/a4VOB1t/YKFE+4mW21RtP4AIc82xPLpagMqAU1YTut0fdWoPRosml9kEOuLY3kS/ffgFxxs56yO4F6/Gm/TOrJxO6d0gA== 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=7qKnuiC65rhEkbfofPyvquNNu9ZViShbbQg1JBZ1HPU=; b=AdC0nzjRWmPDDBEVauutNZwi2qmp336ekOaBy0UQjKOs5czMs/VOGbAZ1qY09HuxpgXArJnHQEk1aLSBEBK5FLXTpgxOInZ8IFIngujJjuiqExm4VbOYJ3o+GinArUgVXuk7sq3bjbKK5UrUCLGmWY6krAK0ep9G/sAVtvM56K0Aro+piZPtF+BpnkZI97PEkOwuWON6wimtMFbBd1ttnLBNH6Z7LvgtwhpQ3xEvsCgQTyJAQXG4HWrgKxc9c4qCyM6n4U4EJISHvTKK61DzEjAz5Z1gaAJ9Ma2mg1xzlKYlYviRrMlR58K1Tiefl50KNiwtj8SXIzUB+5D3gl/aHQ== 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 SJ0PR11MB5214.namprd11.prod.outlook.com (2603:10b6:a03:2df::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.139.20; Tue, 23 Jun 2026 06:29:25 +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.0139.009; Tue, 23 Jun 2026 06:29:25 +0000 Message-ID: <288153df-307a-40e3-96e1-ff4ae8f6bc5a@intel.com> Date: Tue, 23 Jun 2026 14:29:14 +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> 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: KU0P306CA0034.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:29::10) 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_|SJ0PR11MB5214:EE_ X-MS-Office365-Filtering-Correlation-Id: 1781fca7-6db6-4094-24bf-08ded0f0c546 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|1800799024|376014|7416014|23010399003|22082099003|18002099003|3023799007|5023799004|6133799003|11063799006|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: ZwDEA335UPswzrcPMuDC+Yba57GB/KBgGmCkYB/kquT/UqBDePIWXC6xtAvcTFDk13C8mpcJUUPeCLs5BBrBctdCarvmuqb3uPNqjEDN5xizjLnbv4Nor8koGXXsNKrcaKF6ZHvZ8Oavi8we1LE3gUiE79j9m1QXT+nD0QzP0uGOLOCcNupasWygqx6TgorfWpq6/x9kVOsuULfyX1Kgh7e/pO+ltoGOyL1NasM2FZB92QE3JIglt+hs5ExfiRAzvpn4WDRLMg+vQdrlNO+3Y1NuItJ0v2iHCJTZq8rXcCyVcgJj0Pq5RoY64yWeQ0h96d7RbEKfgzDStrS+tUfbGLnr1fPRk9oLEGIA/P0Ejj1+dkcS3FuKkC0H69K8Y41K/PhA7UaLezYNeUSwnpcj4EBsX9LflrthdeQwEPH69vod9Z2vJcE8d7Vi4a8SE8+zdV5R5H/hhm6zrKLYlqL2WhsGmTTT34LuEOzedjOhOJAaGtpQicFwcwsgGbKSSwfi4KiSGnKskNkthuk3xofRiilLm9HPtrRk6b+F101/wr17PhfAZJRGQCeEhibH1VzFqjF8SRMQbzPcbe8j09KLCWuQdPguSlhDpvs8CFBMhLGhSyv1SLqtOInEMF91GKWZJZcdtp8k4WV5naN5nuanfXSofxBUhZXZPeQaX6ODIvs= 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)(366016)(1800799024)(376014)(7416014)(23010399003)(22082099003)(18002099003)(3023799007)(5023799004)(6133799003)(11063799006)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OE5NbmNQZFVwRjNyK3RtdUEvZWdNaWQ1MHhmY0IvbnFkeERWZkZWTzQvV0FU?= =?utf-8?B?cDl4VXhPeGJndjkvZFUzVGN2TWNwY2pvMi9zLzc2UnBZT0t5alNBaytiUWZM?= =?utf-8?B?Zll0ZlNrN1dyZDNPbDAzSmYrcmJ4N0x6VDdPeHQvbG1ZSnNmaWlGQVdjUTVR?= =?utf-8?B?amF5ZmtiZDMxdk9NQVE3T0hPNEdmaEg0TmYwQWlnREx4aGE5S1dFTXhudE0v?= =?utf-8?B?azhXS0cyOUZLeU8vVVhEL0kxdkY5UmdnNnNLSDlBZnBtYkthRzZSNzJ0QjNB?= =?utf-8?B?TjB0c1IvMzJQdHdNQkRhV2lrNkFBZm10TEh0Y000UHFnTkxxQjAwWGxyUnM5?= =?utf-8?B?T0VIdVVjd1R0TkxoN2ZaeWRMU2ViRTJPdXl1emxDVytzbG1MMkIyY3FNM3Zh?= =?utf-8?B?Zk4xL01hYnFNeU9ZQWk5YWtpbTRhUXRzbzVrZWFadGhOVEs2VzRkOTl4LzQ2?= =?utf-8?B?T05xNTNYMzRBdlJFenlZZC9ZcndyZGhNbFA1Nkd6ZHRzQXFsZzdiOURQOTh3?= =?utf-8?B?TVpLaEVNdmVzRXBoeTdoY3F4TXN3RldaMnhxNGg1TVhxWTh1TzMzcE9TczYz?= =?utf-8?B?ejV5OXErUUR6d0ZtNnF3TUprRHpIUDRoMlVFUGt5UE9aSFE0Q3ozNWdJRW9U?= =?utf-8?B?U3lnYjdWd1ovM3hSdWxEVXk2WHdHQXRyYnhObXpuY2gwUTBEdUoveUJJTk12?= =?utf-8?B?ajVubkg2eHJIVTl0c3E4MndZUno4R3VSVkU5Z2ZPdTF5WW4wR2Z6VXhaYjNZ?= =?utf-8?B?dGI1K0FLMVp2dVU3ZXNKSDVLMlF4TVgya3BEMENQeTBZQVM0TllYb3BvUVF1?= =?utf-8?B?K2xsWjJjVG5aMzZMQVc4NWVrNjJzNGdPZ0NFOFpwazFwa1J1UDZkSVkwVHU1?= =?utf-8?B?ek1sWXZPdTFxYjMvT1F5dWkyc3luMU9OdXh4b0grZnVYTnZ2Ymt2N3pjVnRt?= =?utf-8?B?aTlFTlpxL2JveG1sRDVxUkhNOTBFOTlXblExU1Z0VDlsZk9XclZzd0tlcTY3?= =?utf-8?B?aGdGVnpIVHZRSnh3OTJ1TjNNbnpTc3lpUWtyRE81ajk5Q3hEUnhZM2M0b2FW?= =?utf-8?B?cGMwZFpmWmtuVVZHam54MnI1OHpmTHpqdzg4SVFRSCtUMzhMTjErc3BLSkgy?= =?utf-8?B?RmpKMTM3TTZYY2Q3ZEk1YnRyK04ybVkzOUJYVXpheUV3Sk1lalNScDNyUWZk?= =?utf-8?B?ZDdZVzRweWc3dkZuSFpyeFhlNVFzaGZFVk56U0FXYXN6Y1ViVk1XRC9VS1lx?= =?utf-8?B?dzFPMWpPUU1PbzhUVW9JSHY5SVFsY1A0R0RxSUdySXpXcDYydGhkWCt6QUox?= =?utf-8?B?Y1BZeG9hSmtFdmszQWt6S1V3Qm1pM3l6dzdvNUMvSzdRR3EzbHZpWFlTem1R?= =?utf-8?B?S2Y2YUVGRVBkM0VqNnNSYXIwUzNhaDJCcStGbVg4Tmp3bDB5R1RucHJsRUxq?= =?utf-8?B?eWhFblhnRjJiTERzck9NVXZsYjlCTmZpbnVvelpkMDNCTlFreXJOa3NKOXRS?= =?utf-8?B?K01QbFptanB0NXdxWW92SjQzTjBDcnRpc0dvNWpZaklXUTBrTlpZclY0SXhk?= =?utf-8?B?UElldnI2N2pwOWhGYWxkT1ErUHRYTERxZmVtZm0rV0UvdEswWDFNQUNFWDlI?= =?utf-8?B?Y3VYbE1xMHMxbmgyWjhXejNabnl5Ny9vaHJQUm1uNDRUZSt2Z1pReDlmQTUz?= =?utf-8?B?WFJDNjBDZFRmRjNLU0ZUWFJVOXJoN1JKN0F2MW9WbGZ5NkxxVTdkS0NYdlNS?= =?utf-8?B?bjNjK0U1SkJwZjBxVU5Gb2h1enhxYTlrTGpUY0VQSU5uUzdBWTA5VFFJd0k3?= =?utf-8?B?cnh3YkFQZmVBV0p4VXVFVTR3S2p3TFlOa0NWTHdrVEtTRmk5RWNCU3BsOXJD?= =?utf-8?B?eVF0elFwWW5KYkVuQzRpMUVPR1FwUlNVQVBvNTdPM3EycStiaTBMREU4K1Fi?= =?utf-8?B?SStzTXFWeGdlOExic1EzMFFwdXJVZkJoZVJQZ293cEZ5UFFCbTRDR3JYN3pG?= =?utf-8?B?eHdOcWJQc012ZmhhRStGS3JOUUZjZXo3SUNoaTRyMUxwNDVhQnJodWpXOFhO?= =?utf-8?B?NmxwaWZtbHNmRHRsZHBkWEQ4TjltOHlGWm0rV1ZxdWN4ZHpmdHVPUlRwd3BE?= =?utf-8?B?VzVJM0tvUlhFZkNSSEhoam10b3REWGM5WU1DNEUzN1QyYTc3TDV4a2VjcVlz?= =?utf-8?B?L3Z4dTVZSkNGK2ZPQmphN2E2NXJTWkRJWVpVaTVIbHB5QWZBS21EZ3dwTTlM?= =?utf-8?B?WnJ2S0FaMk5xdm5HNExyYWJyWlpxYnZ4M3FxSmNtZUl6V1ZpcXJGUXI1MUpE?= =?utf-8?B?QndENVlLWkUybFR3eHFhN2hqcEFBWmpjQUR5aVVGVWpJUitqQVp3dz09?= X-Exchange-RoutingPolicyChecked: fwIfIIcYHQ2CIfoFhoYVeXJMvqA1XDY7tIMSKUkd8z9cNj7qdgIQb6a6359a52s0pASYcZe0CYCLGR4peTHPBo7AZNyRZe+wIlZG1TG0XzNwKufdwlhVNaiwK1WJXGzxmNKaeJi2g7Krasq5rg3NBZegAPwuHQJGBGR2rKCzwmLaAK9SJ0VeUBA6TGVXKjfJyYBVyhPL/NUcKnkXPSQ+Xsa/PTI09WEwBNBIx6+PQPKoixyZz13A9juZ7ElHg86j5kawbtKyW+IDi4uPED0t9X+HrVBAIsyL0R/V8Feupz866w9k+zfJQdn2BvKno7u+JaEUEJC/DW5SfjnrG9SgPw== X-MS-Exchange-CrossTenant-Network-Message-Id: 1781fca7-6db6-4094-24bf-08ded0f0c546 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2026 06:29:25.5005 (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: P6uvl5+gZCPE9zQjNpCMD3hJoMnCqGl+NjwJvH2760WV8bsqLCEzHudK2pJ/tEGCsGZukP90/W+YP2R4zsOAuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5214 X-OriginatorOrg: intel.com Hi Reinette, On 6/23/2026 5:28 AM, Reinette Chatre wrote: > Hi Chenyu, > > On 6/22/26 2:07 AM, Chen, Yu C wrote: >> On 6/19/2026 7:37 AM, Reinette Chatre wrote: >>> On 6/13/26 12:56 AM, Chen Yu wrote: > > ... > >>>>   arch/x86/Kconfig                       |   4 +- >>>>   arch/x86/include/asm/apic.h            |   1 + >>>>   arch/x86/include/asm/resctrl.h         |   2 + >>>>   arch/x86/kernel/cpu/resctrl/Makefile   |   1 + >>>>   arch/x86/kernel/cpu/resctrl/core.c     |  14 +- >>>>   arch/x86/kernel/cpu/resctrl/erdt.c     | 296 +++++++++++++++++++++++++ >>>>   arch/x86/kernel/cpu/resctrl/internal.h |   3 + >>>>   arch/x86/kernel/cpu/topology.c         |   2 +- >>> >>> Please split out the non-resctrl changes into separate patch with sybsystem-specific >>> prefix to highlight these changes to not appear to sneak changes into other >>> subsystems via resctrl. They can stil form part of this series as preparatory patches. >>> >> >> I see, let me split two of them out: >> x86/topology: Export topo_lookup_cpuid for module use >> x86/apic: Add declaration for topo_lookup_cpuid > > I think a single patch would be ok. Interestingly the subject prefix to > this area is not consistent ... looks like either "x86/topology" or > "x86/cpu/topology" would be ok. > OK, will do. >> >> >>>>   config X86_CPU_RESCTRL >>>>       bool "x86 CPU resource control support" >>>> -    depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD) >>>> +    depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD) >>>>       depends on MISC_FILESYSTEMS >>>>       select ARCH_HAS_CPU_RESCTRL >>>>       select RESCTRL_FS >>>> @@ -538,7 +538,7 @@ config X86_CPU_RESCTRL >>>>     config X86_CPU_RESCTRL_INTEL_AET >>>>       bool "Intel Application Energy Telemetry" >>>> -    depends on X86_64 && X86_CPU_RESCTRL && CPU_SUP_INTEL && INTEL_PMT_TELEMETRY=y && INTEL_TPMI=y >>>> +    depends on X86_CPU_RESCTRL && CPU_SUP_INTEL && INTEL_PMT_TELEMETRY=y && INTEL_TPMI=y >>>>       help >>>>         Enable per-RMID telemetry events in resctrl. >>>> >>> >>> Removing 32bit support is a significant change worth a mention and motivation in the changelog. >>> >> >> The original idea was that MMIO-based access (including CMT/MBM/MBA) uses readq/writeq, >> which depend on 64-bit. Since MMIO CMT relies on CONFIG_X86_CPU_RESCTRL, making >> CONFIG_X86_CPU_RESCTRL depend on X86_64 would simplify the code. >> If I understand correctly, 32-bit x86 lacks practical hardware support for RDT/QoS. >> The Kconfig entry currently depends on X86, which technically permits 32-bit builds. >> However, I am unsure whether there exists any real-world use case where a user compiles >> a 32-bit kernel on a server and enables resctrl? >> If we wish to retain 32-bit RDT support, I can introduce a new config option to gate ERDT: >> config X86_CPU_RESCTRL_ERDT >>     bool >>     depends on X86_CPU_RESCTRL && X86_64 && ACPI >>     default y >> Could you advise which approach is preferable? > > x86 resctrl will soon depend on 64bit, this dependency will arrive via this series > or the AET reworks. Whether x86 resctrl depends on 64bit is not the question here. > > My question is more specific though: > What in *this* patch requires dropping 32bit support? > You highlight above that 64bit support is needed for readq/writeq. That is understood. > Even so, this patch does not have any instances of readq/writeq. This patch thus turns > off 32bit support without any mention and without any reason to do so. This is a very > significant change to just sneak into a patch that does not appear to require such > change. > Got it. In theory, the 32-bit removal could be integrated into [PATCH 6/6], where readq/writeq are introduced. We can add corresponding comments and update the commit log for [PATCH 6/6] to explain why 32-bit support is being dropped. However, Handling it this way would sneak this trivial change into the patch series. Would the following two alternatives be applicable? 1. Add explanatory text in the current [PATCH 1/6] to state that removing 32-bit is preparatory work for CMT, alongside background context on the motivation for this removal. Or 2. Create a standalone preparatory patch solely responsible for dropping 32-bit support. >>>> diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h >>>> index 575f8408a9e7..97c2f6bc7a5f 100644 >>>> --- a/arch/x86/include/asm/resctrl.h >>>> +++ b/arch/x86/include/asm/resctrl.h >>>> @@ -40,6 +40,8 @@ struct resctrl_pqr_state { >>>>       u32            default_closid; >>>>   }; >>>>   +bool erdt_enabled(void); >>>> + >>> >>> I cannot see why this needs to be in asm header ... why not arch/x86/kernel/cpu/resctrl/internal.h? >>> >> >> OK, let me move it into internal.h. By the way, I believe fs/resctrl >> also needs to call erdt_enabled() for region-aware MBA/MBM. Would it >> be acceptable to expose erdt_enabled() in include/linux/resctrl.h? > > I do not see any calls to erdt_enabled() from resctrl fs in this series. > I also do not think such calls would be appropriate. Whether x86's RDT is > backed with CPUID or ACPI is an architectural detail of no concern to resctrl > fs. OK, so I suppose ERDT should only be visible within arch/x86. >>>> + >>>> +struct erdt_domain_info { >>>> +    void __iomem        *base[ERDT_MMIO_MAX]; >>>> +    struct acpi_erdt_cmrc    *cmrc; >>>> +}; >>>> + >>>> +static bool erdt_enabled_flag; >>> >>> What is significance of "flag"? Can it just be "erdt_enabled"? Since it is a bool this seems >>> more intuitive? >>> >> >> erdt_enabled() was already used as a function name. Let me change it to static bool is_enabled > > This could also be named "__erdt_enabled" to highlight that it is internal. > OK. [ ... ] >>>  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. 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(). thanks, Chenyu