From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (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 915741FD4 for ; Fri, 10 Jul 2026 23:45:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.14 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783727137; cv=fail; b=ZR6jpxDS/sdFCXT6GsaF5NHdgFMs2G1rFMBryIq1YCqbJiHKHQ3FjXM+9baoWAHGa5+akp+go2jDMRfmAxySLIHBJSnlPlVUiOMHN8ZFOQr+bbG1LUadrYHdLUADGOeU6zxIScnG63urC3/O72vxJt+Jve7d6l3rQnELH88e388= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783727137; c=relaxed/simple; bh=PL7dOFCvMybViS3V2ktv40NjnJTGZ0lc+I96XQKiBgA=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=d89DNRR6QAxKMldMu++yqA+mSdeGFpoCGkzRhQcEP138B/mLQFwDcpOi/cHag4jHdzo5fRfsi81mRCdGIHj7M8LPxEl+4vcvVMoqZz71kOhE78rNzSS2tzABQb+LcaDaxWp75iEBoATRTNkIJNs+lRpWZxbj2bSgRomRBYgJYAc= 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=F0uYwlff; arc=fail smtp.client-ip=198.175.65.14 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="F0uYwlff" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783727136; x=1815263136; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=PL7dOFCvMybViS3V2ktv40NjnJTGZ0lc+I96XQKiBgA=; b=F0uYwlff8TPl8IMGwLYR2xi2X90qeQsSrVTAK1DyqX7CPtE307rX+iy7 3dGXTZWDXOE6sWPDfK6JGyRFK6hDrIjjMG9Po8E+Jwoq7VOdjMODPgQUJ +rMc9l8vrsIUdM6v7pGIJsYxkB8uAxWxeHtQ4zyiTivSRZbE3xu7AfUWQ S4exnUMXiOTMEjw23pQHjSuHD5WAtASwAWnWSiIDCO88HSpnf3nkGgnh9 O0xhP2wuovrWBRJdsuD5lmN9XIOJsiC3JDWJqTd9Lu7kpOzKZM/SBrQsP L6l0j1SIS6vLtUVPUeSituWdZdBIGmV74RdOk8AOgVCpj/jvjBdb4oVKu g==; X-CSE-ConnectionGUID: U7yYEALOS3y+7zvzerth2w== X-CSE-MsgGUID: 5tS+hLX/TpW+gqSLUC8pqA== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="88339996" X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="88339996" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 16:45:35 -0700 X-CSE-ConnectionGUID: sdxIJN+ySDS1f7PIQxRIkQ== X-CSE-MsgGUID: yV4coBwJSE6AkzqzgNNSig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="255101081" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 16:45:35 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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.43; Fri, 10 Jul 2026 16:45:34 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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.43 via Frontend Transport; Fri, 10 Jul 2026 16:45:34 -0700 Received: from SA9PR02CU001.outbound.protection.outlook.com (40.93.196.53) 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.43; Fri, 10 Jul 2026 16:45:34 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s28usF1TfZewsiv1+0zUP//SBqV4iJ24sijzA+fbJF5+N8nx+ILwkMxJ5DocHCUpu0hS1kKfz2oz70yHRLsbQUUrdloxl55bblAx4jyj8j367rRJB0Y7VZHDfciyS7SZMMlZ0Dwf+dfbBVTCPirHvciROEERpaJXCjoOhaCS3vp0LccGr8gMxa7TqBma4lClLERNJMswEJPjF5mL7h2E1ppM0Z7vEE70mQ5fPKonAkmf82ZRjm7KK3egIq0U8RJ460xKYSQ8mNKybzP86uYDIpwlnPpzeZ3xEBPtp3+TZ9uPj3NnyTK71K/F8Itd9rucpkpV5TsVTgl1Fc+m6gXXVw== 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=GkKr+Ahb4ZjNyc/KdVoSitfw8S1w+TC0NoZN0oOseFo=; b=egzutxPX5ldvY3SHNCPx/+HzzrujsXYpY3YlQ+MokxUnQbnNh/Q884HqcGdQesBNA32jh7XJ06rVJmb0uCqeMiO2lTTa0cXbAKTiJNatoMwREDrTmHzzDNr+7TmkWO91Lwbi3Ha7Xhm5O4IhqbP/ilYdrp+we+7VacoujrarpkUG9Sq4+qVif60Gx+0keM9TGpkdI+UnEw/LSaVrtn0zpCODaaVqS3ZwShJJPhuhmrnFYjHL1DmJL0bHEBMTTa+/bPhL83+gyJ9HFrGesQsewtKnT3Nk7nneJ+fgwJaytTVwumrHsAzJ9eExQCA4ebfiMWRB8k9KBQdNo6P7SzrIUg== 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 CH2PR11MB8833.namprd11.prod.outlook.com (2603:10b6:610:282::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.8; Fri, 10 Jul 2026 23:45:30 +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.0181.014; Fri, 10 Jul 2026 23:45:30 +0000 Message-ID: Date: Fri, 10 Jul 2026 16:45:27 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/10] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online To: Chen Yu , CC: , , , , , , , , , , , Hongyu Ning References: <950d1001ae525871a20599e8702f6de4dbc9d482.1782866200.git.yu.c.chen@intel.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <950d1001ae525871a20599e8702f6de4dbc9d482.1782866200.git.yu.c.chen@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4P222CA0018.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::23) 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_|CH2PR11MB8833:EE_ X-MS-Office365-Filtering-Correlation-Id: 762a56a4-79db-4aab-07e9-08dededd5363 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|7416014|376014|1800799024|23010399003|18002099003|22082099003|11063799006|56012099006|4143699003|6133799003; X-Microsoft-Antispam-Message-Info: DnH2LwJto7L00Hs+DWD7ZmzXlQfjHQx0JLIxu/OFcJ+EnYOpHF0vDxdk2KXvnsAJ+W+oHgHbu0fdz8YZhanIwIIRqpeZYaUSFNVD/QjUR4LcF42qt+hWqEthKnzlzd5tfTp344QuSG8RWSxgiZK1E0lr3xF5oXxJDvF7+76klgI0Txcadd08Omp8h/Af8LnYPTlseJNpYhgYY435nBYvVbQBEFhUbbRsAuM4aTEY/R+eIgj3Q89Dsw/odhHT6Pw9hS03NiVk4PojNXPeVBPJGXFP8DIuEbas+AtJSUwcjNx7Gn8MBQ2JoY6XZLfAXNHGAufDdw5NC/3D7orrt6fHL7KiLeAQQXhDBif1Ym3oqPgbsCRRJse0/zOreVdvgtoIhNVMgB9b1J4Ngj9daSsE1+RThwbgdzm1ykHDCi5ngexuLhUAMmo3NruPf2nA7HXaMTbpov/PCOqVqLsnKQsGj2Iunqjk4xSR7Hqzt/0ouhw5eZjVANOhJodbZR4tqQEvL+3HxtJMyRjDpGsdnMMFD0hDi4Jw9k3/JomCVIAusjC4ivxLi+admh/S3y22A/O/CxAb6W+Gk9Mtnhd3K9+69fXsvJ9lqANrvslGYzTUaSDiAf/v2Z7diqyqQLV90mVsEqpREHiwMK/WoNX7stvgnm0/AUkLuBkzEg30tkbVJpA= 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)(7416014)(376014)(1800799024)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(4143699003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?enpxZElUMHNKTVFMYXFqRGo0V1FJOU1rK1MxQ3JRbkZ1aGN6S3F4ekRzNWRq?= =?utf-8?B?NUNlMVExRTcySWZMRU5tYVEzY1BDODZMYTB4MlFxNk1LbU9tMUNlSHR5Smsv?= =?utf-8?B?dTVZaVBnYnliL0JuTk5Oajc2ZjV0Q09sQnB5QXhPdGJZQktCWTlSbnRzbzA3?= =?utf-8?B?Z0M4YzdiUktBTE1vUENzeGo1NVpUcDk0TFdnL3pFYWowWFF5WHRpZW5XaGVH?= =?utf-8?B?VC9Yazk4VEEvS3dqNUtuZmtMUWNnQ0FaRFRlWWQ3bnkwQXFCT1NrVmtZNGc4?= =?utf-8?B?Q1FZcmkrWlAwdmVydzNrcEhUaTZkMFh3eG1WdkdtT2VXMERWdUdXRE82dk40?= =?utf-8?B?UU9MNG9KdWpuWHNIcGMwamdmZWZwd0V5d0ZZQ01vSTFJam4xSTZQMm1rLy84?= =?utf-8?B?b1FyRU5tMEszRTZaM29qZHEyNllpcDNkVnJIZDBtVkYxeSt6a2J0ZDBnbGtN?= =?utf-8?B?dFJrYURDZlpBZkxQZm5WZ3A4NThYV2hDNUUrNVJxRGUwQUpYcFFvekppcG9z?= =?utf-8?B?UEdtNzdMUWZ1MWhZOVRnMURtc2VNWFNyblA5d3NCeTl3MkROYUdRemVVMTRZ?= =?utf-8?B?Y2g1YUx4bEJHbDFvLzh5WUU2OHNqNDFBZWk3dXZXaHBORGhOK0k3SWY2SzlP?= =?utf-8?B?NEZCb2pVdks5aEZocUE4U3VpZkJaTXA5OGpyTXZaa1dHM2x0TnBiWnpiWWRK?= =?utf-8?B?TTdpRW5lVVpCOWZ6ZnViTlYzbnBUWUJScXZwblA5NU5jaUwrQWRJbWxhdDhW?= =?utf-8?B?MmtnS3h3Z0tHS1VKNUZYbHNXeWtUTUg0ZW9TYVlhNDNkeWduK09mKzA4bHB3?= =?utf-8?B?Q2FROFRNZU1uR3pWQk1tUklMd05VWjJ6QW9pcThoZEhtWEVuUHZvOHpHRG9G?= =?utf-8?B?ZHpYSEtIdWszaGd5bXUzU05GeU9Ta3BENnQydkkvTFJwcTlTTFFPRUs3WkZy?= =?utf-8?B?eUU2S2JLTDlVdnF6N2srTWtIT3RTRFVPKzlXcnRDc3F1WDBFOUsyWTczcU9Q?= =?utf-8?B?WlhJaUZ5QzFZN1A2K1UrQUhieGRTRnpWZ0l1RzJPOWsycTNrM2NFOTVaNk9W?= =?utf-8?B?UDBXeGt6OFppdFplc1l4UytDZDRCekMyU1JsUTJyL0pnYlRwUFRsTjV5NUVK?= =?utf-8?B?UmVvSzRDbmFsYlgzRlFOenZDMFkwV0NVS0ovcGsyZ2hkV1RCSngvRWIxUG43?= =?utf-8?B?cWdBazlaSjJSUlJxa1JpMmNFakVIQzZIM2cwQzEwajhoVElhQmdJeWNqdm4y?= =?utf-8?B?V01QajFod25jbTZJd3hKN1BaZ21tbmN2TGdTM0VSTUdMckZzc0d6dStna2V5?= =?utf-8?B?Z3paSzUvL1BORWRaalBIbll5TjZ4RmF3VnRoT3E0bHFSaGZNOTdEaUtmYk5P?= =?utf-8?B?WEFFdXh6dm9OZW9MMnFNalE5R0wwNVo1YXh2M2RlNENheERXZURNT3V6bHFv?= =?utf-8?B?NUNoOFg2VmV3YjdwUDRsN0ZWcVF2QUVITE0rRFN2K0xCYzNqN05uczRPK1oz?= =?utf-8?B?WWNyRkxERlVSNnpuQ01pRG9WMGtVend6TUJ4OEE5U1lveHJSSldqdmsrSUww?= =?utf-8?B?WmowVzloOFI0K1A1UHFza3A2TzFqY3VmUGhBWEhnNmtUR05GWWxVWno2RXJT?= =?utf-8?B?ZmRXa2JLeVhLUEtZSjJEOWpIMGo4cVZwMytNZ1hjOHAwSDRCNFg2UlZVYkFS?= =?utf-8?B?NVIxTzdLd0pHZEtlZU44NmVhRm1Kd3JwckZGVXdKbGQzZUk1N3FucXNsdVcr?= =?utf-8?B?TFhRN0IxN1FHRHBiVkV0ZE92d2RiMHlVVmtvK2s3M1g1VlNxVHZOZDNJdEJk?= =?utf-8?B?bEhMTU1MeTYvc0pUTnZPTzR4SUd4UnlSYjNUTkt5blpjcFppSFo5Sksvbjdl?= =?utf-8?B?djltUURobGJFWGxQQTFOaS83dkQraXNsckQ5QWM3a2RyVTRweUVlM21hQnRa?= =?utf-8?B?MWMwVzJqVXo0RE5pTUZneERFcnhWSjAxd3NSdmdsUEkwcndWNGVXYXd5R1Ez?= =?utf-8?B?OHdQY2ZoWVhlTjhYTUkwcEN6NjhDazRXMTFnNEZWeFQxa1ZjUFdWWmRpNHlp?= =?utf-8?B?OFVweEtpUTF2K25HSGZodDE2c0hZNjJlQy8xOGp4SXFsTDFiMm5KRnZ4K2FU?= =?utf-8?B?UzhPYjA5UjNJS3ZiUHlXVWZiOTNRbFM0S1ZDOUIrYVRzUHdsZU15bGpXUmJr?= =?utf-8?B?V3Y2U090WnNQTjFYWi9XenZMNmRIYWRaZ1YyejFjMDd1Q2NDcnV3MlFZVDdn?= =?utf-8?B?ak5XWTFGMTVxUHVmOG1MeHBwMW1KQ2t1OEVVZVBlSnMrRExFTG9TWUt0a0FJ?= =?utf-8?B?TnZLRlhKTFBiUzJpdWFqc1l6V1JZTlR0blgxWTZ3WXpPSmZsdG9wbzRzYk1L?= =?utf-8?Q?i5xoqOI23hXT8zgY=3D?= X-Exchange-RoutingPolicyChecked: XPlMLXoHL949oPwO6g3m309YnsDU0h2HRHIZmKCsDGVCqON7DLwOIXRdqoFae/JNIvz+p5/BwojnmMn7hwgPPfqoRKDOaRN5R2s6mJl/W0/zyPTvEqa8sDfEiaxu75/FJwiZu1xJ+2aE7RYdeqFkp/Kf9lLZo6/1kPo1KzbHUDDwY4zUj/4A0sgq1WtTrOvo7T0iLR84PNA10GgiG6HqK/0xHUJQSAavnv9ORJK/ewWXzPICIYdD+oQljDmkhnO/Y2YNwXz8NLzzJ8Khsw35GTJ5fLOsl+uhExndn4/5Gtcq5cQlmuc1jQGcgS1po0OUmxxmDTOzrNKGiD86ta8U7w== X-MS-Exchange-CrossTenant-Network-Message-Id: 762a56a4-79db-4aab-07e9-08dededd5363 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2026 23:45:30.3003 (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: HqWJJhFrbtZ/cJqOHLrATfJFftgUvEPOBBH5qf5w/2seLYobjokrH+PonN7eHBjo+hwYBvpIMdHUiqhNnUwBXVqvlyVdDcyVfan8hhMMMvQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB8833 X-OriginatorOrg: intel.com Hi Chenyu, On 7/1/26 6:45 AM, Chen Yu wrote: > After the rdt_hw_l3_mon_domain has been created during CPU online, > attach the pre-parsed ACPI ERDT table information to the > rdt_hw_l3_mon_domain to facilitate monitor data read via the > ERDT and its sub-tables information. Please follow tip guidance for changelog by starting with context before jumping to what the patch does. > > During attachment, a sanity check is triggered to verify whether the Please write in imperative tone. > CPU mask reported by silicon (CPUID leaf 4) matches the information > exposed by firmware (CACD table). If inconsistent, this CPU will > be cleared from the legitimate domain mask. > > Suggested-by: Reinette Chatre > Tested-by: Hongyu Ning > Signed-off-by: Chen Yu > --- > v4->v5: > new patch. > --- > arch/x86/kernel/cpu/resctrl/core.c | 17 +++++++++ > arch/x86/kernel/cpu/resctrl/erdt.c | 49 ++++++++++++++++++++++++++ > arch/x86/kernel/cpu/resctrl/internal.h | 4 +++ > 3 files changed, 70 insertions(+) > > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 23925bcd71d7..2e95586ebe45 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -549,6 +549,19 @@ static void l3_mon_domain_setup(int cpu, int id, struct rdt_resource *r, struct > d->ci_id = ci->id; > cpumask_set_cpu(cpu, &d->hdr.cpu_mask); > > + /* > + * Verify whether the CPU domain information matches the ACPI data. > + * Skip adding the newly created domain to the list if there is a mismatch. > + * ACPI information should be assigned to the domain prior to its insertion > + * into the list, in case others might iterate the list in parallel. > + */ > + if (erdt_l3_mon_domain_setup(cpu, &d->hdr)) { > + pr_warn("CPU%d has inconsistent domain information, do not add this new domain\n", cpu); erdt_l3_mon_domain_setup() already contains a pr_warn() when there is an error, is this pr_warn() needed? > + cpumask_clear_cpu(cpu, &d->hdr.cpu_mask); > + l3_mon_domain_free(hw_dom); > + return; > + } Since the rdt_hw_l3_mon_domain was just allocated and the current CPU is the *only* CPU assigned to it, erdt_l3_mon_domain_setup() should never fail? I do not think any CPU checking is necessary here - when the flow reaches l3_mon_domain_setup() it can just assign the ERDT domain directly, no? > + > arch_mon_domain_online(r, d); > > if (l3_mon_domain_mbm_alloc(r->mon.num_rmid, hw_dom)) { > @@ -591,6 +604,10 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) > resctrl_arch_mbm_cntr_assign_set_one(r); > if (!hdr) > l3_mon_domain_setup(cpu, id, r, add_pos); > + else if (erdt_l3_mon_domain_setup(cpu, hdr)) { > + pr_warn("CPU%d has inconsistent domain information, remove it from the domain\n", cpu); > + cpumask_clear_cpu(cpu, &hdr->cpu_mask); I do not think it is necessary to add the CPU to hdr->cpu_mask for the ERDT test to be performed (more below). It thus looks to me as though this ERDT domain assignment should be split - the error check is only needed if there is a header and if that finds a problem it can just bail early (before adding CPU to hdr->cpu_mask). Something like: hdr = resctrl_find_domain(&r->mon_domains, id, &add_pos); if (hdr) { if (/* This CPU's ERDT domain a NOT subset of hdr->cpu_mask */) bail; cpumask_set_cpu(cpu, &hdr->cpu_mask); } switch (r->rid) { case RDT_RESOURCE_L3: ... if (!hdr) /* l3_mon_domain_setup() initializes hw_dom->d_info without CPU checking */ l3_mon_domain_setup(cpu, id, r, add_pos); ... } > + } > 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 6405df9be817..6c1df7e43eab 100644 > --- a/arch/x86/kernel/cpu/resctrl/erdt.c > +++ b/arch/x86/kernel/cpu/resctrl/erdt.c > @@ -212,6 +212,55 @@ static __init bool parse_rmdd_entry(struct acpi_subtbl_hdr_16 *rmdd_hdr) > return false; > } > > +/* > + * Associate ERDT table information with this domain. > + */ > +int 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; > + struct list_head *pos; > + > + if (!__erdt_enabled) > + return 0; > + > + /* > + * Find the erdt_domain_info that contains this CPU, Please use entire line length available. > + * compare erdt_domain_info's cpumask with the cpumask > + * exposed by hw_dom (derived from CPUID leaf 4). > + * If yes, assign the erdt_domain_info in the hw_dom, What does "If yes" refer to? > + * otherwise this CPU should be isolated from resctrl. > + * For example, the hw_dom reports CPU{0,1} are in > + * l3 domain0, CPU{2,3} belongs to domain1. Meanwhile Please use consistent terms (l3 -> L3, cpumask -> cpu_mask, etc.) > + * erdt_domain_info reports that CPU{0,2} are in domain0, > + * CPU{1,3} are in domain1. So when it comes to CPU1, > + * a mismatch is detected, we should remove CPU1 from > + * resctrl. CPU1 and CPU2? > + */ > + list_for_each(pos, &domain_info_list) { > + d = container_of(pos, struct erdt_domain_info, list); list_for_each_entry() > + > + if (cpumask_test_cpu(cpu, d->cpu_mask)) { > + if (!cpumask_subset(&hdr->cpu_mask, d->cpu_mask)) { Consider the above two tests, the first, cpumask_test_cpu() already checks that CPU in parameter belongs to d->cpu_mask, it is thus not required for the same CPU to be a member of hdr->cpu_mask in the cpumask_subset() that follows? The callers currently add the CPU to hdr->cpu_mask before calling erdt_l3_mon_domain_setup() and then remove the CPU on failure ... that thus looks unnecessary? Caller can just add the CPU to hdr->cpu_mask on success? > + pr_warn(FW_BUG "Mismatch detected, CPU%d in L3 domain(%*pbl) and CACD domain(%*pbl)\n", > + cpu, cpumask_pr_args(&hdr->cpu_mask), cpumask_pr_args(d->cpu_mask)); > + > + return -EIO; > + } > + > + hw_dom = resctrl_to_arch_mon_dom(container_of(hdr, struct rdt_l3_mon_domain, hdr)); > + /* No mismatch, assign the ERDT information to hw_dom */ > + if (!hw_dom->d_info) > + hw_dom->d_info = d; > + > + return 0; > + } > + } > + > + pr_warn(FW_BUG "Cannot find CACD domain for CPU%d\n", cpu); > + return -ENOENT; > +} > + > void erdt_exit(void) > { > struct erdt_domain_info *d; > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h > index 299d7222f693..7d9100b7648f 100644 > --- a/arch/x86/kernel/cpu/resctrl/internal.h > +++ b/arch/x86/kernel/cpu/resctrl/internal.h > @@ -92,14 +92,18 @@ 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(read-only) read-only in comments can be made explicit with a const below? > * > * 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]; > + struct erdt_domain_info *d_info; > }; > > +int 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