From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (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 1140336B915 for ; Tue, 4 Aug 2026 05:27:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.11 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785821228; cv=fail; b=Bpwf5GY/ZvFmZeycVulXYl9zXWafT9rISO7n7gTpSDNzYJupRLqfGzOtga49drQ9rWhDtwtZy3Wr8WDCzT+cHIMwpEccDlE9Az7m59S9awBOeqJJxg4bEx7+V0yDT8+nEVym9qXDKjIcIVNGLNUQGTa6Zt/xcMnqUzSMu2P5IjY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785821228; c=relaxed/simple; bh=PsHkf+fuICralHVlPjOYoq7ZKsM4xM3K/zEiu7n93yA=; h=Message-ID:Date:From:To:Subject:CC:Content-Type:MIME-Version; b=rMRJpbAT/SFh5+BPc2kwMFdszE6ehTD0QwTB60My0iElUdm8R3n7bXuahONwQYHmYrrh7reCZhllYngF4oUqECINEhJgOjYV7fjQVM0UpnVle0HLNQ18LvL6s7AX9YEG4ooDFManh5RiCsjqNVn6MeeOE70MduJYK8GDAwykla4= 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=csIV3YDd; arc=fail smtp.client-ip=192.198.163.11 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="csIV3YDd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785821225; x=1817357225; h=message-id:date:from:to:subject:cc: content-transfer-encoding:mime-version; bh=PsHkf+fuICralHVlPjOYoq7ZKsM4xM3K/zEiu7n93yA=; b=csIV3YDdgwte0rae553xujMS1jzyqV6ZxoFYKGAK+40IJgZmUFm2mngB vY5u+LGbLDUb7M2w33CYapdRtNVLxsqEjjSzRFlXiVZW9ZzOiaezi/94T 403JNRGcZx5GG/cfdKPxprSeszgyuao1dtVUUsC3FExNVcf10GjD3whcG yaFI+9AYN3Kds2hj/snZ+VKw5NqE0cZyU6JPwemmjIsV3j5JDdiqDQQwh nJTaP0t+fSVoCiRZtj7/FG7vedvwVVu4CEptgnjMELyrkQ+1i+u2ryVnn hCpJ06kNTpr6bLsn1cFutYl+17nMKFi6YvUJCTxetPiQa2l0V4swzTd4I w==; X-CSE-ConnectionGUID: hn6T630SSLq5FeQWJXtg0Q== X-CSE-MsgGUID: 1YF2XSyqR0y9LbyIUmoy9Q== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="96955007" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="96955007" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 22:27:03 -0700 X-CSE-ConnectionGUID: 8FTmb62jTiOTzz8Zev6QLA== X-CSE-MsgGUID: KJlwsbVtTh2K0RPS/orO6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="291342260" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 22:27:03 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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.45; Mon, 3 Aug 2026 22:27:02 -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.45 via Frontend Transport; Mon, 3 Aug 2026 22:27:02 -0700 Received: from SA9PR02CU001.outbound.protection.outlook.com (40.93.196.59) 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.45; Mon, 3 Aug 2026 22:27:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fa6WNLRZ5JcIF1eDRpQs1UveSWihsqDFwDTtIxUD4yhpjY2g424CN9fJiM3quMpMW0L49inREf6gJ+r/oN9HNaaZhy4q6gA0AFBjlxWhv7H8yyR6FViDBhna+tHrGR7Dzk4c01ZGSnbXPKzl6oSNgmd/xyACMxgRpuw643+pU2sP0giZuvq2SiWR3sT51uRF0qbS9oWxBIfZ/LljGdtMPUXUMteiw66jQ06Dg89wrjJSBNo+8Z3sx7CnnWaQSoG+Df7KpNMXtHLutkXWCiN9rlTOB4AvKZfDX8xIaHVauGuJ9z8mRMa3CyLbLqY7wv+mqUPG2gMs3niE4QMJRkUOZA== 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=U8L8rPPLm92ZUY1cSsNpty13ypAuQeukXfQglJyi2r8=; b=ImXudmo1DFIc4KkvO1juMIAIeL8n4Zb8SKckUMvME2E4ByByTXjUmyq1N3guC8ivH2FphooWJz4HGiOVWKQk3rV2n1cCxfBBBwXN5G/vEVqw5OSw3tN/el1JTYcOrNqVmlNsvVdErMW68ZcEGDXgztiw9S52hpuEAwCx4ydgasEHN6zWguMcH/pWduXMgpGSZ4GtL3gugDMomoKaE4wn1bQWq3z4BIFaXDPsoZK0Nv+LeiEgOZx+wPpQH9YbrsM8QeObhEy/hfRCIQ0Ye/pZCXOHyuF1ZQObcIDWT05ZAvg0nPi/NG5vrB0PGPZkWqpBitor+6nP77mjxyXTHMBmmQ== 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 SJ2PR11MB7425.namprd11.prod.outlook.com (2603:10b6:a03:4c0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Tue, 4 Aug 2026 05:26:53 +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.0270.016; Tue, 4 Aug 2026 05:26:53 +0000 Message-ID: Date: Mon, 3 Aug 2026 22:26:51 -0700 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Reinette Chatre To: Tony Luck , Ben Horgan , "James Morse" , Dave Martin , Babu Moger , Drew Fustini , Fenghua Yu , Chen Yu Subject: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR04CA0263.namprd04.prod.outlook.com (2603:10b6:303:88::28) 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_|SJ2PR11MB7425:EE_ X-MS-Office365-Filtering-Correlation-Id: 155136bb-1a22-4e43-158d-08def1e8fe4f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|1800799024|366016|6133799003|18002099003|3023799007|56012099006|10067099003|11063799006; X-Microsoft-Antispam-Message-Info: cjxxe1nmKXxOXV4rmnc+nIXnGKXLZVRD42JOHy9tq49ZesthhkfdDbqsyPF68gmQ/oqzTIbNKNoD+GnadYlwTmDIgdAKwwowRbU+l+XtfaEMZRWZcEcaLXmjIxRgbnrkpgYRSYexFsMa6WQqvOmmutNhy0vKo0UGbEhWgDgtRYlSKtPuGxtVPSQJeNlhHjndSZKJc9hxk8EiaeTsyi63bbxsa58b1Wvc+A3kKKBqUq1lDYLAfzGMmIyAsG9SZ9KNse2Mym5i6e8zYsuci0SdJ6jutvS9AP8f4jdaA4ao9nTpA301hiX5uCHAKFdCv8roq1E0x2u7oBPg1+xGRm0BlLMA7B9R2LykQeEB9AOfapnaUrF0s6cstoEnBgY1t1kTTk+hYO7UEw/yoZiOn7LSsJH+yXjpFu0TSF5DW5kdpKaRgYBqWpV+ldSS8P61ETJtyJPJEsIKysmAhvFa1IBS2XSXgj0QY4MWLBxWymOzX5CQS1aPZPEdMqv33v2/Kv6LLFsKujrtKOMl2TWV/QACgNIjnrk0O59xIguzWOlUGO1fmjpDEksJiZxuYOH7gqCoEa3QPNlZlqR0x1hLGfXqJcfB++Eq+eNsO3VAzLYQOaKZa4mhmP2wHC974pS5BJGC 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)(23010399003)(7416014)(376014)(1800799024)(366016)(6133799003)(18002099003)(3023799007)(56012099006)(10067099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dGpIb3V4L0RDVjJ3emlHWFJFWldZVGxNMDFXTG4wd2pjRWJKNHQyL3lOb0F2?= =?utf-8?B?MHdpTTFnS25kWjFsUjU3TFpnUFMyeWxSa284TGU3bGdmYk54bHV1K0U5emMv?= =?utf-8?B?SkZia0J4YjYzWnljd0F0QW5mWkJuRUZmWWZjMHBNbmxYSXF5Y3BUcTRUTkpO?= =?utf-8?B?NFVDSklqeGNoOGc3RjBEOWZNYmczQjNBZVNWblVLQ1BycjhZTys4TVkxQkdV?= =?utf-8?B?TlM2ZUlHSjlkQTgvYVVuNW1taHY0RVJTSVJMdWlxS0FvbXk5QU95SUp1OFNZ?= =?utf-8?B?clV6RWVudTRHYTdNTHJGd2MrV3pjeENQMi9qWWlDSzRWTWNzbUZHRnJBNnkw?= =?utf-8?B?V2RhS1gyU1FVSmJFTUkrSTduWlhOcjBOWG83UDBSZlFhTDRsUUZJcnpjRFhG?= =?utf-8?B?NFpEZzIvODNLWEZBMWQwRWtqbEZxUFM3RWhjM1BENmJHektLSUMxMW1ZWDJi?= =?utf-8?B?aVRTeVdUOUxyUVgxMHVUMnkxaGhncWF3dnY4STM3RDJFSEd1eWtwVlJ6citF?= =?utf-8?B?T01hbEl6S01jcitXV3h5dUhmRk0vU3UwTGJuaEJEZC9qQ3lUSHZrUkUyTk1F?= =?utf-8?B?UVRWT1ExWXlyZ3pMZ0ZRYWVDWVR4UDlYSWc3TERBeHJtS1A5WnhkU0hvNXAr?= =?utf-8?B?M1pSY3FibjIvRDhpRzUzc29JS3RVck5RTTNFdjd1clJ0VC9IblNSWGJETHIr?= =?utf-8?B?WmNsR3ZZMWpEdjNzQmtMVFhQckZZQ0NoSnYvZGJhcHZYK2dKQjNrWnIvNnBO?= =?utf-8?B?QlArRERRWmR4TG1sTXBtVDQ1MTcwakNCanlrNUJkbmw1ckl0S1hpa3Q3anlC?= =?utf-8?B?SUJOVC83cC9MUU4wb3A2Z2lWYUw1dlJYYXZ4SWNOQkpPWmZmanp1dVV1QVky?= =?utf-8?B?elhrWE93VS93ajBpMGdaNmhlLzRhTFAwSVBkOUFtNEhWMnk0YXY2QThxaDkr?= =?utf-8?B?VHJBSVFjOU83NDA2K3o1cldUTE5CdHhTdnBoRHZsQnNQU2ZwSGRqM3VJZ2Fh?= =?utf-8?B?ZjYxYkF2VVladHhIUnBLd1dJd1lFSG1YT2syQTU1RlppSmdrRk1OUkxZd0Nt?= =?utf-8?B?Z1FCWDhZZmVmeGZTMzhmcTEzQ1FyeCtzcXpLNmdGQzV6ZVRvWXRkWEVLNEgr?= =?utf-8?B?aWhOclpKcElNMXdESW8vVUNudkR1cyt3ZWVvalRraFJQcUQ4Y3R6dk9VS0RU?= =?utf-8?B?bnE1bUpWVFhLL05KQXBqTGd3RmFMT3NxOEx5SytLR0hPUm52Z0RlTCtWMk1R?= =?utf-8?B?blc3WUNONU13eURFUzNkckgrSVYwQ0ovVDVHcG5PQmtkZDQ4dTB6OHFMU1Bm?= =?utf-8?B?RkZyd3N0UUdmUWMxUjdMOG5KRlllVFZ4SzNHaGtjLzVUWDhGTCtpTGM5UW51?= =?utf-8?B?YmpVcWRDZTdDMjNMWFk2N1hYQ1dMelVVZkFzQnlURS8vUlZHc0F1bjVyQURN?= =?utf-8?B?eHV4UWkvcHkrdUJ3VjhxcnpITGZxMWJZZWdUQ05wYWliNHFXcVFjSi90U0N3?= =?utf-8?B?NHdXT01sWFFPUlhnQk1pTm9TNm9qNTZUdC9GejVUVmtBTDlTREsrVGJ2QkM2?= =?utf-8?B?Rmt4bE1QRWFkSGRnbmhTcmRna0dKSGF6V3d0UXhHZjl6YXAvbnlBdDgwZ200?= =?utf-8?B?THVTcjB0Z1B2WllTeTcrRUVJSXE5RUR0L1p0cVBuSTJ4RHJPVUdkQlc1bEJU?= =?utf-8?B?aU4rOS9PWisxWmx3M21hQ0RJR2piMzFxRnNEUGVDY0h1RU9vRVg5ZnlkdHFs?= =?utf-8?B?Q2I3WmROay9INUQ3RkpVMmtrTitOYUtSdnVCSHhuVHF6b2hVUHVxQ2VOdEU2?= =?utf-8?B?S0V6T3ZEMnVuVFY0LzREay9FRFlLRFpnaDlDRXl0NUNBNDY4eXI5L205cmRL?= =?utf-8?B?VVFBVUU5Z1k2MUdIMnhUN3I1QmhTeGgxVDNsMUNNWmdrRVZaMzZRb3h3WFZO?= =?utf-8?B?WE5NQTI2RzZ6RWVPMDdvcUo0WCtZQmRUaHpnVEp5elQrWWRNdms4aStid1pG?= =?utf-8?B?d2hQWEVMT1FMTm1NSlVTL1llbGZaMTlHU3RSTzZYM3FsSU1Ub3VtZlhBamhZ?= =?utf-8?B?ZWtvamo3RXUya2Rla2t0SHNLa3VoZ3Q4WU9GN2UxbU1LS214eVE0MGZSRld4?= =?utf-8?B?S29lYm9HWFVWMHl1N2NESWF5ckJ0UDNqWC9YMy93UlhiNFpwVThCQy81VHda?= =?utf-8?B?bFJ3SE5KZHUzSVZuVXNKa2hrQ3RQRGFPK0pMVGROOFJVLzVSSGN5VXlVV3Zm?= =?utf-8?B?WXl1aitpY3AyRjV4LzI1cmtxaDR5OFhLUEVBYWRQNU1hK1dsTjBiYmc3ZjJB?= =?utf-8?B?S2hNNzJoS3I2NTkycG52QjRoOTYxTDJKYUdoR3RSbmVQdHBvSnVvTERFbHhP?= =?utf-8?Q?XIiHlC/jQuCl6K/o=3D?= X-Exchange-RoutingPolicyChecked: IxUm6YNrSDAB9Ica2/i795/Vbq6atpsOCQWvrP9ulMqpRoq1NfhzDnDiFFX00AAIr1h1ucARZs4JlCfJzkSFHsnVo5HK5E48bJNKL1gu+dA3c4nhKfJCL1LQlqwegcwLGcLGxGk1HOqnc61AFoyhgaOdRJaL/Zms7OhrOXFlarKMm0fYt45QRgyBACuuMWNB1PGNPqMYm6Leit8ofiYzsYyduSdsmx5wJdaeXM+XVy/PuMk3tpSPZtujeyTnVqeAUeXyKh/SuoIWcnWgQ4kDrI+ROxXXfzBwaBnF/4uIzDvdxWPfoNu/uIs8h7ZydCtSUCudy+Vs/lwmndn7g9/zEA== X-MS-Exchange-CrossTenant-Network-Message-Id: 155136bb-1a22-4e43-158d-08def1e8fe4f X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 05:26:53.5585 (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: pH55ChfVyk+JooMp9qJUQdJKKZaoLyBAmEyPTbLVQvvogQLp6KbL+xDYXit4jh9XzDkhLpUA02AXr6dffke2ohoBcHn+73Hz6MI21ci0N00= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7425 X-OriginatorOrg: intel.com Hi Everybody, I understand that folks are eager for this work to settle so that features that depend on it can make progress. I do have a request if you have a feature that depends on this PoC: Please do not fork this PoC and keep changes to the PoC code in your fork to meet the requirements of the feature you are working on. This is resulting in duplicate (even triplicate) changes to PoC floating around. Instead, please collaborate on this PoC by responding to the patches that need changes/fixes to support your feature. If the patches do not exist yet, please participate in the discussions that plan these changes so the work adding the discussed features is not duplicated. If you already have the code, please feel free to send as fixups. Doing so will help this PoC to settle faster and help meet the requirements of the feature(s) a couple of folks are working on. RFC v1: https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v1 RFC v2 of this PoC can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v2 The list of changes is long. For an overview of the new interfaces, please see the new documentation patch: https://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git/patch/?id=2e2d0140e857eae2ba3e71e8d9c595897649599a Remaining Opens: --------------- - MPAM only compile tested. - Only "SAMPLE" code provided for x86 to demonstrate emulated controls. - Architecture should take care to restore control value of legacy control when switching mode from "native" to "legacy". This may be complicated by a legacy control backed by multiple native controls and thus best handled by architecture. This adds a complication that resctrl cannot promise that switching between control modes will not be destructive since a reverse mapping may not exist. - When switching control mode to native the top level control info files stop returning information. This could be considered "work as intended"? - Add relationships between controls. For example, cannot set "MIN" control value to be larger than "MAX. Unclear how to do this in resctrl fs when considering that the relationship may span between enabled and disabled controls. This is potentially something that needs to be managed by architecture and thus potentially without a consistent failure to user space. Changes since RFC v1: -------------------- There are many changes since RFC v1 since I aimed to address all feedback (but please see the deferred/dropped list below). If I missed anything it was not intentional. Please feel free to point it out to me. User visible changes: -------------------- - Expose bitmap control properties to user space. -- Only expose two properties: - resctrl_ctrl_bitmap::min_cbm_bits exposed via new file "min_bits". This drops the familiar "cbm" term to not make the control specific to capacity. - resctrl_ctrl_bitmap::cbm_len exposed via "max" file -- While "shareable_bits" is technically a bitmap control property this does seem an opportunity to deprecate it since the IO alloc support proved that it does not accurately represent shared allocations, "bit_usage" is the best for that. - Add support for control flags with "linear" as first flag of the "scalar" control and "sparse" the first flag of the "bitmap" control. Include flags in output of the "type" file. Suggested by Chenyu: https://lore.kernel.org/lkml/90ae82da-02b2-4058-8c1e-f16df3226d8a@intel.com/ - Add a "default" field to a control using the "reset_val" name suggested by Drew and return that instead of always using "max" for the scalar control. The "MIN" control can return its minimum value as default. Suggested by Ben in https://lore.kernel.org/lkml/29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com/ Use case from Drew: https://lore.kernel.org/lkml/aiCBratZchVFVhws@gen8/ Drew suggested name as "reset_val" https://lore.kernel.org/lkml/aiOrznnZjTGywMna@thelio> - Change "resource_schemata" to "schemata". Fenghua: https://lore.kernel.org/lkml/d0f84cef-58f5-4b84-8171-a0dfe8fa6829@nvidia.com/ - Fix the control alignment. (Chenyu and Tony) - Drop the "per control" scope. Move the "scope" back to being per-resource and do not expose a per control "scope" file. This helps to support new resources like node scoped MBA that cannot emulate the legacy MB control. Also supports emulated controls by ensuring that all controls associated with a resource have the same scope. - Support emulating legacy control. - Support multiple backing controls for a legacy control. - Expose new per-resource "control_mode" file that user space can use to switch between legacy and native controls. Only the enabled controls are shown to user in schemata file. - The new "native" control mode is only supported for the MBA resource. The solution is generic but there are implications for, for example, the resctrl features that rely on the legacy cache control (cache pseudo-locking and IO alloc). Defer support for other resource since there are no immediate plans to have, for example, the legacy cache control backed by something else. - Architecture differences imply a lot of architecture flexibility in support for emulating controls. Architecture can expect resctrl fs to only stage control values in controls that are enabled. Within architecture there could be rules that determine what to program based on the control's emulated controls or it could dynamically program update callbacks when the user changes the control mode. RFC includes sample code identified by "SAMPLE" for the latter that demonstrates one way to solve the x86 variant where the hardware self supports both legacy and finer grained controls. - The top level legacy control property files stop returning data when the mode switches to "native". - Draft of documentation that describes multiple controls and emulated controls. - Fix Intel MBA tolerance to be 10 to match the "round-up" implementation. Changes not user visible: ------------------------- - Rebase on tip x86/cache with following applied on top: "x86,fs/resctrl: Improve resctrl quality and consistency" https://lore.kernel.org/lkml/cover.1782857711.git.reinette.chatre@intel.com/ "x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch" https://lore.kernel.org/lkml/20260709093111.367851-1-ben.horgan@arm.com/ - Fix initialization of controls list in MPAM. (Ben) - Dan Carpenter reported an issue with missing unlocks in rdt_bit_usage_show() that was resolved as part of rebase on top of the new info_kn_lock()/info_kn_unlock() helpers. - Drop "mpam,x86,fs/resctrl: Make memory bandwidth delay a resource property" so that memory bandwidth delay linear flag can be a control flag instead. - Separate adding the control to struct msr_param from the change that makes hardware update functions part of control. ("x86/resctrl: Make control update properties part of the control") to create new patch that is moved earlier in series to support bandwidth linear flag property being part of control. New patch: "x86/resctrl: Include control with information controlling hardware change" - Rename the controls to match their type to reduce confusion. Suggested by Chenyu: https://lore.kernel.org/lkml/773353e8-b2a7-4c20-b6fa-195b0b301107@intel.com/ New names: struct resctrl_membw -> struct resctrl_ctrl_scalar struct resctrl_cache -> struct resctrl_ctrl_bitmap resctrl_ctrl::membw -> resctrl_ctrl::scalar resctrl_ctrl::cache -> resctrl_ctrl::bitmap - Switch subject prefix to be "arm,x86,fs/resctrl: ..." when changing both architectures and resctrl fs code. - Switch to MPAM subject prefix of "arm_mpam: resctrl:" when only changing MPAM code. Changes deferred/dropped: ------------------------ - Let "scope" form part of the control name. Drop this since the current plan is to have the scope be part of the resource name for new resources. - Introduce new per-control "status" that can be "enabled" or "disabled". Drop this. While controls now have an "enabled" or "disabled" state internally, this is not exposed to user space via a file. Instead, the "enabled" or "disabled" state is exposed to user space via the entries appearing in schemata file. This simplifies the subtleties when the hardware self supports both legacy and finer grained interfaces (aka RDT's region-aware). - Defer emulated control support for cache controls. - Supporting different monitoring scope is not part of this PoC. Any feedback is appreciated. Reinette