From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 A069B383C7B for ; Fri, 10 Jul 2026 23:53:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.8 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783727610; cv=fail; b=hjqLs4IVZYiKm+K5nsonOzDD5yPJYOsBpbLAYj3vFyN5QJRM2YAWjf01r9g2k5UhDoyBGlgMRavO9N71xWdKfmLI7gq+Cybi4O87ODc+Y10x05POICW//qRU++LAewdEgQnDCOtu9g8IX3bb4tlCGVsmxkvorKhRLKRyD7IPqvk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783727610; c=relaxed/simple; bh=dw+ivgIpGEXSbR4F02t6/lYVm2azES+eJ/fH6GgzV3M=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=o/h7r/Xhn6myMzv1xNDtXhLVcuVf5w+u4KVHUbml472uz4DuBXcLyXy+iKXx2PRkkfjIy2JUJPpZLWlcM8NiZVsKT6qtCFvlv0BQ4ukF0rIXlyoit1whkpraKRz3vDhJISFVfnLgchTEylr7+nsOgmx2q4hnfLIjzlrikAqLTcw= 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=Q5BQLtEX; arc=fail smtp.client-ip=192.198.163.8 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="Q5BQLtEX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783727609; x=1815263609; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=dw+ivgIpGEXSbR4F02t6/lYVm2azES+eJ/fH6GgzV3M=; b=Q5BQLtEXsS14j3pE/zD0EHqOu67y7H3d1g+wuxYnFlba7Qs+WpnTf0XP 504x3eXFSt1tFQUfo8V1QOkIsiV1VkZsMIP56pjOi9iKqoqc0Pw5m+sZB 7QigjSL/x3IgmW2sLocqzr/kguWIf8k5yUAkYBUpDiLHqbnpvFB6C6bHh qUDmFbJLl8JimsCsj4lRWcOUGN6i5ALtbnx9nUPJ/D4wQI/Qv33zoBaDX Kvq1Wc2q8ee8EqUStgkdgeAf27XfINC0WhChchTkYVGXFDiVhGvG6SqMG 6gfV4Gj6EaNzWduYjnefWESa6QdOf5Lc+DbzkWzv0MWf2BcCL9dpnmLAx w==; X-CSE-ConnectionGUID: A1G26/vJThyHXPQXCH0U2w== X-CSE-MsgGUID: VAgBDFqMQ1udJIq+ANHMPw== X-IronPort-AV: E=McAfee;i="6800,10657,11841"; a="101978591" X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="101978591" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 16:53:28 -0700 X-CSE-ConnectionGUID: 3MwaoYryRcCQ03vOjiabDw== X-CSE-MsgGUID: v4hZqRtPQsWGZxbFYHe8Dg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,154,1779174000"; d="scan'208";a="248634289" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by fmviesa009.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2026 16:53:28 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) 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.43; Fri, 10 Jul 2026 16:53:27 -0700 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) 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.43 via Frontend Transport; Fri, 10 Jul 2026 16:53:27 -0700 Received: from CO1PR03CU002.outbound.protection.outlook.com (52.101.46.59) by edgegateway.intel.com (192.55.55.81) 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:53:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HzYscGGQBpo4j79Vo9RfNQyx1hMYnjI488DjhOnudQwVwA8kiYscsgIN/0iddJa+xAwaOjgw2VHTPooxDESbbD9PV5b1JYJDJvkE9B5SIqkobyRqalO6UJvRGrVEgQT0SAcynSvb3C3neEePN7Xr6ou98zNMb/SubWWTKSpb0DiKt4EWOXVCqn7T+Ik/WNzkzezzTcv+erttqayg1rVdSj74fps32aHioDs9J3I5EGmv00hY67dLwqOCpL5CjeG4eHour7Bt01p75pEQwiBOs1+PQ+xWcox4S8hiyiPXiodcfrPa8nWrMFSRmRjt3VGwQczqyFWzlXcBD3DA9Wb7ww== 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=UHDvgxIkH1+7h1hNknOJnQHrE9BgJbL6SXuSoaiPF0w=; b=J3TshWYD+JCxu9pA+OpiZ9lkySdTIaaIZhDnTBfqyecTRmNJ0tqb0EPxsjo51ayt/TOyIWFp2FA/nKM+J63JtCVCRW6wX2tyEr+v77OX0+FuHW44+y82XLmuWFGHhdxPvCjN8prsbnOEH5ROKc6Pj1HHhStGu1e0hLoz3JWWm3r1mtXEClEvR3i5TMQzWQBKd/uitKH2INj8mC2ebNtVCan0485Dc6+kNxLGlTMkZSHaH8EUY5mw3AX9sqPtiZKcpjjzYz5j1xBf2GAkMJ0LX4MJZTIAfUbX2vqDJuzq9zrL9xPtUFBwAwr2e/P16S/7+8wCfFx/lD6qYZNChGGvrQ== 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:53:23 +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:53:23 +0000 Message-ID: <41efb127-686e-4fac-bac1-ff70351ec2c3@intel.com> Date: Fri, 10 Jul 2026 16:53:20 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 09/10] x86/resctrl: Introduce helpers to read L3 occupancy via MMIO To: Chen Yu , CC: , , , , , , , , , , , Hongyu Ning References: <28ea318efd3f2379116268c2f2e9cbffee98f138.1782866200.git.yu.c.chen@intel.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <28ea318efd3f2379116268c2f2e9cbffee98f138.1782866200.git.yu.c.chen@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0177.namprd03.prod.outlook.com (2603:10b6:303:8d::32) 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: 26b13d3c-340b-4736-3d7c-08dedede6d04 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|3023799007|11063799006|56012099006|4143699003|5023799004|6133799003; X-Microsoft-Antispam-Message-Info: dpA//R9zmL0mC0RLx1X5Rh1Sc7E5rn9FkKiYBrOmXpVsmhJttvw5srA7D2TJ2MWrbiRFloxoSvOzOfl6Xx5CijPIq8WSLgDjlTD6/gGX8HmNwRnkAPOlB+bleKstyhgbJSPcYAOdZbs7/2X5uow/y1nFG3x2W3N0bY+psAJbWDndFNzLtnEgkFMjFVU/nykLAqxnCDxdETJ0EcNdw4xZL/+rS3ltPfDxBpgkhfcB4zkauyUxGcEK7ZB81MIJeRIxdIn4GUu1KqGtNa5DdhwfMLD2XEa6vcIzU+lhBVBPy9dgE/BxMHCmGvxc036PZ7wWd7o9NiFCei+qSWMYsOY9Wxevsvh8dFgOUh89aYtfJLQ+vPseX42Y9CmjQqpIFSVr8b1GgLhy1N1ZknqCXUm1iSLWJcEa1SCmKOsw87+LNbRmyTGhxeCHJNsEBmGog6yrCPwEi1F9bd88yH8fsPGTBe+pI40dzh14y7PhA8ioIQy1UkX2jN1tpICNYnl/cKUeVrDpN5E1+IYq5KhttDNbd+BrDkganpJi4kxGikMr0PDJGG4DPAWlipbI6Jw9RHL8tP940o+og3p0/yjx4/Gq5C2Jgat3d1o6HErUWKNDAlEIid4uWRqbLCVe68nfDZGd7OoNXrj8jzBfJ26zgx1pt1FLpJjKsOcKEmjq6wTq2Bc= 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)(3023799007)(11063799006)(56012099006)(4143699003)(5023799004)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b0ovb0UrZHBxMERFTjR1K2oyMkNTbVJlRE82Y05OMGt6YlNKWDd0Zmp2ckFk?= =?utf-8?B?RlloOW1GdTRFY1hUZEo2RnArZ0RVekRSZzJjNlRSY1VaaFIvR0orVFlWT01H?= =?utf-8?B?eXAzWWdtQVlsWXdPajBHaE1MVmlMakV6R2pYa3dSNnlNeGlDTW53QUNYSy9k?= =?utf-8?B?V3A3Q2owT2lIN0NyVkRSeWNOcWZUZmU5dnNHNXdqNURNNDZTMk9YUzhNeGty?= =?utf-8?B?UnFIMXhMSWtaY0E5ZlAzZ3VIN0R3MDNIVEVmOHNkVGpLVGtFZHV6bXhUanpz?= =?utf-8?B?TllnMW9ZbHVUYjNwVkt4bHYzVzZ2V3NKN0NXdzdlWFh6NnF2MGFvcHppQUtF?= =?utf-8?B?VVY5SEpocmZxZDJBTGxYOXBFME5kWmpxdWRzVnpWcGRqSmhVamdyV3BSUmF5?= =?utf-8?B?RzF2L0szbmpZaUNkdkVDMmhWTHlTVWNiSm5qUzY1Vy9LY3BPdHV5WU1wZ1hx?= =?utf-8?B?UHZJYzB5R1pFcm1hWFRXOU0zb3JGTFV3VWRHeUt2VTFaUTBTV00xTGdmOW5O?= =?utf-8?B?bHNBck9XM3d4RTAvRk5rM0VVQnBSTWlWRU1JdTNNYy9VOVhzaGxhSjBGazNJ?= =?utf-8?B?VDlRaHZ5VzEzTnYydklGaHdTVk5VTEhVY1NlOWY5Q042cnZiRnB0d1JZcUpo?= =?utf-8?B?d2FvdmMyU0x1azd1NWd4cnQ5Wk5ZV1c5L1JOTFFUbEhQUURVOWpNMnZ5aUc1?= =?utf-8?B?M1A1MnZ2bU9DWUZZdmJLV3UvcE9sTGk2bDVhZFd1UzV2ZTlPejE2M25BY21Z?= =?utf-8?B?REsrK3oxWHVBam4vcWd1WlB5SzduUkFQSUdSZm9tZjg1RHNkcmxhb3pMZHNC?= =?utf-8?B?ZWpBRWxUT0h3VDRxbm1WcGpsK2JPZ0tWS2RCdzUyaVl3OFB0cHVoZzg4alZY?= =?utf-8?B?dlBWcFJrcVR4YlpVTlJ2WlVIZWRVeGdRNGRSRDdrS0JIQzExV3VjQVZsdnMx?= =?utf-8?B?MktnVG5BUjcwN0F0NnRSbTRqQm13RjJKNXFreTY0NklRS25vWGpsSWdqbTJZ?= =?utf-8?B?WVJVUzQvLzhnVDRvNFJ3SWRUU1RvL0Iyc2NBNmlkdzduOU9GT0I0bStMMTFB?= =?utf-8?B?U3RrZ3FxZjhyTkhoUGQ4US93ZHF3WlBUcytwY3B1NGlybncyOUU2WnVOQW9K?= =?utf-8?B?ekZZU2dwWFU4bjlJWkZ6dEtzcEV4UUNPcjN4dDg1R0czQXhWTUN1UmRoTzhz?= =?utf-8?B?Qm1OYUVUMTYwSUtxL1FaSnE0RFdDUlJ6OFVHWjBBVVN2L0hrMmNVNldqSzdu?= =?utf-8?B?S3BibU9sVlBFeUsyVTVHQ0NXbVRQZTBldS9MMit3S1F2NmU2UldQYlpLU2pl?= =?utf-8?B?VC8wY1FqR1o2WnMvVjVpejBNeXVpZWE4Ni9CcG14TVBwdzJxclhzUGppd3VT?= =?utf-8?B?UXE2N2RJcXdpZllrTTZoRjU4K0RvdlluL1J3QkpOWnNLTFQyZkQvdWR3azBk?= =?utf-8?B?TElyYnF5UWxoand3N2NDSHFpNWduTkZqenFyLzZqVXhYeHFNMUdzRVZxazFL?= =?utf-8?B?ZTdGbjJoSjJ5Z1ZPZFVFVklaUDJDSVFKcEF0SFJ3cUJtUFpNSHdlUU5hL1hy?= =?utf-8?B?RHFHd29IdXMxcUJYdWhCRmFoVFlPTkYxSFlycXJ6ZzRGUFFsUFRMakFJOHdi?= =?utf-8?B?Y3pGTWdSOHRxL09RcGhEUnlWSTZEaFJNWHpMaEdsOVNrcHdhcStFYmUxTnBt?= =?utf-8?B?M0RNQSticS9GdjZLZkpIdHluQWlqQUVjazAxY3d2V1MvQ3ZDbEtDSS9kZG10?= =?utf-8?B?YkpXajF0cWpwRmxUMW05QW1SVEdPN3dVL05VdDRwMm9uOG9MeFZORFhZREs3?= =?utf-8?B?NVdVZVRQOWlUNERDSFg0Z09OSHdieGhmL2o5OE4zaTdTdm9xemVGNFl5M2VX?= =?utf-8?B?eUZ0SEt0VWpHamdKME9QUUt4U0pvQkdkYnhtV3Ayb1FBRHBSYjBqZHU1NXp4?= =?utf-8?B?VXpFRytkU2ticy9oOWJRSmd1ZjB6MGYvNUg3bGUzdDE0MjB4YTBCV1NHUDY0?= =?utf-8?B?SEh3NjcrNFVnOEc3dm45dmd2VjZYU1JSU0hkM3dXaW1LOUVBdUxGOEZyRndv?= =?utf-8?B?VGRpWmUvT1J6a1NSYnhOa1ZCN2dEbGg3eWpZS25UQzZuZjdYMHZsenIwMHc3?= =?utf-8?B?a2N0TW5VbVl4QjNFTkZkL2w3RUIwaEc4VkFVZkR2RXArdE5rb1pNUTZJLzgy?= =?utf-8?B?SW9lbytQQjkrWlhNdjFBM2lrMUtFNU1ZSU1RT29pNEFXckdPUXQ2N0VqOHhJ?= =?utf-8?B?OWxZMEpFMnM2MFAzS0ZyTnEzL2VaK1JrME4yV3RCa1FIRGdVeVlSallSdFNQ?= =?utf-8?B?MlYyVitDT2N3aU9xeCswSDlHUHdoaVNiRk1kZE9xbEx3Smthb2FsblBTNW90?= =?utf-8?Q?zG/QJHE1J+6ULsKg=3D?= X-Exchange-RoutingPolicyChecked: ABbmavs9jWklZ12wovJO8Lvk50eRg+fzBRuMT6BApeqph4UgnsqhsLCVb/4dot1zBtNdLICb4HiFgbXQLw487F7v5LzNfH1r7aDgzSEHnlZ+iSLLnpaGJdxFAew2HnW8FG4k5zHJbYP6ltbZaQSmocQmpXi/ijo+8WOgRbFx0KNMs5YhHY06AWY+pqTq8SyfuoPZy8mUMTJRDLFl9D4uzYG/C+20X2dNLKgKYrhuCFtpHVZOI7yPqmzLfaoyZtgHbZnfh9LjjHKvjeVQH+uvS/3SgX8Wk6dcGUoycISL0Wu/smke6Tx4ikOfphaOLMU5XqWCkD330Xp5ttOZbZlgog== X-MS-Exchange-CrossTenant-Network-Message-Id: 26b13d3c-340b-4736-3d7c-08dedede6d04 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:53:23.0544 (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: VFBNDpufL7yj0EobOTwdc5y8C1Fel6BbpjkDS/PqFv4S893Hkk2tnT6JHuX9MA6KgRNkKFbi1nF0U9bJE0DVWNfq/pP87ppxknZqBLknQwI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB8833 X-OriginatorOrg: intel.com Hi Chenyu, On 7/1/26 6:47 AM, Chen Yu wrote: > Introduce erdt_cpu_has() to verify if a specific RDT feature is > backed by an ERDT table. erdt_cpu_has() is derived from rdt_cpu_has(), > which not only considers firmware (ERDT table and its sub-tables) > support for an event, but also considers userspace input like > "rdt=!cmt". erdt_cpu_has() expects the same input parameters as parameters -> parameter although this can be more helpful with something like: "Similar to rdt_cpu_has(), erdt_cpu_has() expects an x86 feature flag as parameter." > rdt_cpu_has(). > > Introduce erdt_mon_read(), a helper that retrieves monitoring data > for a given RMID and event ID from an ERDT domain. erdt_mon_read() > leverages erdt_cpu_has() to check whether the system supports the > corresponding ACPI tables, such as ERDT and CMRC (Cache Monitoring > Registers for CPU Agents Description). It invokes the low-level MMIO > read callbacks (introduced later) if supported. > Since this patch contains two logical changes, can it be split? > Tested-by: Hongyu Ning > Signed-off-by: Chen Yu > --- ... > diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h > index 575f8408a9e7..0fd4bf85f628 100644 > --- a/arch/x86/include/asm/resctrl.h > +++ b/arch/x86/include/asm/resctrl.h > @@ -49,6 +49,8 @@ DECLARE_STATIC_KEY_FALSE(rdt_enable_key); > DECLARE_STATIC_KEY_FALSE(rdt_alloc_enable_key); > DECLARE_STATIC_KEY_FALSE(rdt_mon_enable_key); > > +bool erdt_cpu_has(int flag); > + > static inline bool resctrl_arch_alloc_capable(void) > { > return rdt_alloc_capable; > @@ -131,6 +133,10 @@ static inline unsigned int resctrl_arch_round_mon_val(unsigned int val) > { > unsigned int scale = boot_cpu_data.x86_cache_occ_scale; > > + /* ERDT itself factors and rounds the data within erdt.c */ > + if (erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) > + return val; > + This does not seem to take all usages of resctrl_arch_round_mon_val() into account. This function is also used to determine a valid (user controlled) threshold for the limbo handler because it needs to be ensured that the threshold is a value that the hardware can actually measure. Speaking of the limbo handler ... I did not notice any mention of limbo handler or any changes to it. From what I can tell this implementation keeps one limbo handler per domain even though occupancy counts can be read from any CPU. Is this intended? > /* h/w works in units of "boot_cpu_data.x86_cache_occ_scale" */ > val /= scale; > return val * scale; > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 2e95586ebe45..5932cf813cb4 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -895,6 +895,29 @@ bool rdt_cpu_has(int flag) > return ret; > } > > +bool erdt_cpu_has(int flag) > +{ > + struct rdt_options *o; > + bool ret; > + > + ret = erdt_support_features(flag); erdt_support_features() -> erdt_support_feature() or maybe just "erdt_supports()" ? (only one feature can be checked at a time?) > + > + if (!ret) > + return ret; > + > + for (o = rdt_options; o < &rdt_options[NUM_RDT_OPTIONS]; o++) { > + if (flag == o->flag) { > + if (o->force_off) > + ret = false; > + if (o->force_on) > + ret = true; > + break; > + } > + } > + > + return ret; > +} > + > bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt) > { > if (!rdt_cpu_has(X86_FEATURE_BMEC)) > @@ -982,7 +1005,10 @@ static __init bool get_rdt_mon_resources(void) > struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; > bool ret = false; > > - if (rdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) { > + if (erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) { > + resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, true, 0, NULL); > + ret = true; > + } else if (rdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) { > resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, false, 0, NULL); > ret = true; > } > @@ -1000,7 +1026,10 @@ static __init bool get_rdt_mon_resources(void) > if (!ret) > return false; > > - return !rdt_get_l3_mon_config(r); > + if (rdt_get_l3_mon_config(r)) > + return false; > + > + return r->mon_capable; It is not clear to me why this change is necessary. > } > > static __init void __check_quirks_intel(void) > diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c > index a5754d64fcc1..1114ad4e3b42 100644 > --- a/arch/x86/kernel/cpu/resctrl/erdt.c > +++ b/arch/x86/kernel/cpu/resctrl/erdt.c > @@ -18,6 +18,7 @@ > #include > > #include > +#include > This include is not used in this change? > #include "internal.h" > > @@ -27,11 +28,17 @@ static bool __erdt_enabled; > > #define ERDT_VALID_VERSION 1 > #define CMRC_SUPPORTED_INDEX_FN 1 > +#define UNAVAILABLE_COUNTER BIT_ULL(63) Not used in this patch. > #define RMDD_FLAG_CPU_L3_DOMAIN BIT(0) > > /* Bitmask of valid sub-tables found in the first RMDD, used to ensure all RMDDs match. */ > static u32 valid_subtbl_mask; > > +bool erdt_support_features(int flag) > +{ > + return false; > +} Why not provide implementation here? > + > int erdt_get_max_rmid(int cpu) > { > struct erdt_domain_info *d; > @@ -50,6 +57,11 @@ int erdt_get_max_rmid(int cpu) > return -1; > } > > +int erdt_mon_read(struct rdt_domain_hdr *hdr, int ev_id, int rmid, u64 *val) > +{ Please use accurate types ... rmid is u32, evt_id is enum resctrl_event_id ... > + return -EIO; > +} > + > static void __iomem *erdt_ioremap(phys_addr_t base, u32 num_pages, const char *desc) > { > void __iomem *addr; > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h > index 6eb0fdea6b63..ecb44f82581e 100644 > --- a/arch/x86/kernel/cpu/resctrl/internal.h > +++ b/arch/x86/kernel/cpu/resctrl/internal.h > @@ -278,8 +278,11 @@ static inline void intel_aet_mon_domain_setup(int cpu, int id, struct rdt_resour > static inline bool intel_handle_aet_option(bool force_off, char *tok) { return false; } > #endif > > +bool erdt_support_features(int flag); > +bool erdt_cpu_has(int flag); > int erdt_get_max_rmid(int cpu); > int erdt_init(void); > void erdt_exit(void); > +int erdt_mon_read(struct rdt_domain_hdr *hdr, int ev_id, int rmid, u64 *val); > > #endif /* _ASM_X86_RESCTRL_INTERNAL_H */ > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c > index f4f4c9015ceb..e6d7037f000b 100644 > --- a/arch/x86/kernel/cpu/resctrl/monitor.c > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c > @@ -279,6 +279,10 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain_hdr *hdr, > > switch (r->rid) { > case RDT_RESOURCE_L3: > + if (eventid == QOS_L3_OCCUP_EVENT_ID && > + erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) > + return erdt_mon_read(hdr, eventid, rmid, val); > + > return arch_l3_read_event(hdr, rmid, eventid, val, r); > case RDT_RESOURCE_PERF_PKG: > return intel_aet_read_event(hdr->id, rmid, arch_priv, val); > @@ -423,6 +427,11 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) > { > unsigned int mbm_offset = boot_cpu_data.x86_cache_mbm_width_offset; > struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r); > + /* > + * Currently assume all CPU domains share the same maximum RMID > + * value from the RMDD table, use CPU0 domain's value. > + */ > + int erdt_max_rmid = erdt_get_max_rmid(0); > unsigned int threshold; > u32 eax, ebx, ecx, edx; > > @@ -430,7 +439,8 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) > > resctrl_rmid_realloc_limit = boot_cpu_data.x86_cache_size * 1024; > hw_res->mon_scale = boot_cpu_data.x86_cache_occ_scale / snc_nodes_per_l3_cache; This implementation still mixes CPUID and ERDT enumeration. Above, for example, a system that supports ERDT cace occupancy counts is expected to provide another scale value via CPUID? Could you please clearly separate ERDT and CPUID enumeration. > - r->mon.num_rmid = (boot_cpu_data.x86_cache_max_rmid + 1) / snc_nodes_per_l3_cache; > + r->mon.num_rmid = (erdt_max_rmid > 0) ? erdt_max_rmid + 1 : > + (boot_cpu_data.x86_cache_max_rmid + 1) / snc_nodes_per_l3_cache; Here things are also intertwined. Above essentially means: "if cache occupancy counters are read via ERDT then use max RMID from CMRC and let it *override* the RMID from CPUID that is appropriate for memory bandwidth monitoring"! I find the code like above to become increasingly obfuscated. This patch starts with a promise that "erdt_cpu_has() indicates support for ERDT feature" ... but then above generic code uses the more subtle "erdt_max_rmid > 0" as a subtle check of ERDT support. Having the CPUID and ERDT support be so intertwined with subtle checks just added for convenience makes the code difficult to understand and I am concerned it will be error prone when folks try to build on top of it. > hw_res->mbm_width = MBM_CNTR_WIDTH_BASE; > > if (mbm_offset > 0 && mbm_offset <= MBM_CNTR_WIDTH_OFFSET_MAX) > @@ -477,7 +487,18 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) > hw_res->mbm_cntr_assign_enabled = true; > } > > - r->mon_capable = true; > + /* > + * If the platform has ERDT but the SNC is enabled, > + * this monitor should not be enabled. (line length, please check entire series) > + */ > + if (erdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC) && > + snc_nodes_per_l3_cache > 1) { > + WARN_ONCE(1, "ERDT is enabled but SNC%d is enabled, monitors for resource[%s] should be disabled\n", > + snc_nodes_per_l3_cache, r->name); > + resctrl_disable_mon_event(QOS_L3_OCCUP_EVENT_ID); This seems backwards. I think this highlights how ERDT needs to be handled separately and not try to wedge into CPUID enabling. I am surprised about this behavior. Isn't SNC and RDT supported via MSR? Would this not prevent users from using cache occupancy on an SNC enabled system when it could be supported? Is a WARN actually justified here? Could SNC capability not be checked early _before_ enabling ERDT cace occupancy event and if SNC is active then the MSR cache occupancy can be used instead? > + } else { > + r->mon_capable = true; > + } > > return 0; > } > diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c > index 6a7c86a72c51..2cf03e4cf72a 100644 > --- a/fs/resctrl/monitor.c > +++ b/fs/resctrl/monitor.c > @@ -1034,6 +1034,12 @@ bool resctrl_enable_mon_event(enum resctrl_event_id eventid, bool any_cpu, > return true; > } > > +void resctrl_disable_mon_event(enum resctrl_event_id eventid) > +{ > + if (mon_event_all[eventid].enabled) > + mon_event_all[eventid].enabled = false; > +} > + Please see https://lore.kernel.org/lkml/20260701213553.15222-5-tony.luck@intel.com/ > bool resctrl_is_mon_event_enabled(enum resctrl_event_id eventid) > { > return eventid >= QOS_FIRST_EVENT && eventid < QOS_NUM_EVENTS && > diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h > index 73ff522448a0..dfde025432ab 100644 > --- a/include/linux/resctrl.h > +++ b/include/linux/resctrl.h > @@ -420,6 +420,7 @@ int resctrl_arch_update_domains(struct rdt_resource *r, u32 closid); > > bool resctrl_enable_mon_event(enum resctrl_event_id eventid, bool any_cpu, > unsigned int binary_bits, void *arch_priv); > +void resctrl_disable_mon_event(enum resctrl_event_id eventid); > > bool resctrl_is_mon_event_enabled(enum resctrl_event_id eventid); > Reinette