From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (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 1E8732DCC13 for ; Fri, 17 Jul 2026 16:55:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.10 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784307342; cv=fail; b=PFI+px3lolh64unQB6cvoqbZdCIUCOhUNUl9o6GY8ZmX7D0sVCS03d8aMeYPqrKhHFBunBMQhdeQ9M/X00/QYOYLtcyAL5bbynjVyhrWfvO7Mu+wzrVxaDStkl+xIuUgvvYW2ZiLLWgunQ/vUmAgIlQqGdFMpV08omT/3jguQmY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784307342; c=relaxed/simple; bh=zgKoOmNujcvQaGT4zyM0NzZZdNBE7uA5hFg3xnat5tQ=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=JCbDJDQwGoJYLsiOzJ/iGq1zCopu/2dU08xgx6gIWaydQpr0YNWSxks/Fmu3OFeUkNWXdKNVHU7xT0uq9C38Bkq9tl7UwzJp3wKbRr+Mrb6lEKsvQaUgv9g/jjRA1sxuUyUrgVDMGmyZ9d/nMho6E/KB4cIdi6VWxbYtZifPDbc= 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=bVXNmbAO; arc=fail smtp.client-ip=198.175.65.10 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="bVXNmbAO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784307341; x=1815843341; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=zgKoOmNujcvQaGT4zyM0NzZZdNBE7uA5hFg3xnat5tQ=; b=bVXNmbAOUByk28DGqThl8RR1SrEgn6w+AEr0DFhHy8FfMs4LY7dTszQq 4mLL/hBtIh/pNaMg6+LyDqpDi3oT57xJdvxzcdpZIOc6dOIwXVK984d8R mJGlqwFqn8w3NReS6ugo9N5mka7Q8rX4BZJwUwFrkYl+RAh5+Ntx0qHKd lclAZM5sQriy4n+LVX3exBF62WqA07PvAnDPeNXtGbQNqNIkUWfupsKd6 s/Vss7vw0vHvjNI9LLBcJZ3T4zAN2MqV1Eff8LUqS1aD4LaYrb0HWKqwl s+wMT5E3Ez0TZHiW1nyTFGfPK0CaJdMnp5oNr6XDAgpKrScCHPLzkKQrV g==; X-CSE-ConnectionGUID: 44KfKjDQSbW+D/4mm1DaBw== X-CSE-MsgGUID: 3/BeApK1SVeW8ZLb0vxWKQ== X-IronPort-AV: E=McAfee;i="6800,10657,11849"; a="102407704" X-IronPort-AV: E=Sophos;i="6.25,169,1779174000"; d="scan'208";a="102407704" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2026 09:55:40 -0700 X-CSE-ConnectionGUID: XPjK70HPQ7Sl6q3Sk+YJ4w== X-CSE-MsgGUID: eh8chdZ3SGSHLM0x5t9Utg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,169,1779174000"; d="scan'208";a="252864286" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2026 09:55:38 -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.43; Fri, 17 Jul 2026 09:55:38 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) 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, 17 Jul 2026 09:55:38 -0700 Received: from DM5PR21CU001.outbound.protection.outlook.com (52.101.62.68) 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.43; Fri, 17 Jul 2026 09:55:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aibs7nsyaivLOyzzBOLY0IVxaU4CkjgoqWpzsMFrkgEdzNQqQ0wtGHmHYNN1BH1FXXukxNbMR8F8rzIdRS6xLRE469U+KtE5Q5AXxaA1Tf1hlHDmeDBmGNUJK8kLO2eDqlZK/GwrV3sIrQWMLg/6muEKKuuqqjnoV1zzh0D8SHX9T63mzfeeeUcYzN3SvuSZOQu6MUMpczsyov3w7oiedLdnFr6w4rrAkJ5NNGqnbyC3jk3nu0lCkZWTjQ+93etPLEOz8V9hcc8lpKdk57Av9VvAmXlttZpFwJx5AY9rMxWghjq+H2OrJXCFQ//fTb3sibvDaSNpIKKdvbdsZg6txw== 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=InzUn9ZlZxNf+WStLlx50LY1SwtpD/wJDAp5z/GMoWY=; b=bpWxmCBVd7mbkB8HkivJ+bt+L7mMCAe1/q3w5Di1A3ftetL/vfgbugW6fEUbbU/CzyAXBT7R1ik0pWf44qbqgI1KEu8q6NKXYQuDmSLx2B4+SD6PGospDDLEhIQvCvYrqVCqjS0TaMuxLH2IcymaNzAAWG7XUnKpZs/J9tUEGKdoUn9IxR6MzjQpqJWgJ/Ut1ljl0mWzV99LPexf3qZgdJrj5MKCZPx9P64BoCndfceKbj6TG26nDxuCETRwFzd+ct2nGnEqkb3bsMjt6t9dEUHMRvc1BH7QqUkgq4kZcHVKGn29/Wqhx59D+56GboONLIiUABoo10vfJwMUozFu6w== 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 DS0PR11MB7531.namprd11.prod.outlook.com (2603:10b6:8:14a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.13; Fri, 17 Jul 2026 16:55:33 +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.0223.011; Fri, 17 Jul 2026 16:55:33 +0000 Message-ID: <87e4ca90-01bb-47e9-8892-0d2d56468bc0@intel.com> Date: Fri, 17 Jul 2026 09:55:30 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: "Chen, Yu C" CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Ben Horgan , James Morse , Fenghua Yu , Tony Luck , Dave Martin , Babu Moger , Drew Fustini , "chen.yu@linux.dev" References: <5ee87762-1898-4b62-94da-85b3e9917ecc@intel.com> <62701203-c4a3-4ec2-a9af-602e1fc15863@nvidia.com> <8f9f78dd-e3f5-4b35-bc72-0eb5dafdcedf@nvidia.com> <36163a81-9737-49e3-93ef-6c392f7272f0@intel.com> <0fc6df54-26c7-43fa-948a-528cd94937f1@arm.com> <9049378c-699a-4155-b1e4-737a1d7265d5@intel.com> <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com> <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com> <4b297b46-995b-4b94-9fb0-bd69276dc957@intel.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <4b297b46-995b-4b94-9fb0-bd69276dc957@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR04CA0247.namprd04.prod.outlook.com (2603:10b6:303:88::12) 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_|DS0PR11MB7531:EE_ X-MS-Office365-Filtering-Correlation-Id: 19907801-49bc-463b-1398-08dee424371b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|7416014|376014|3023799007|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: EvpZL9Y7/IzZIWmfOh/02FIw1VnI38BMo/a1GK8CKC9LcR4Lq9lbqygrJv/7bazbzevjJQEChcte83Gbu3EehxbcbgrWlTtxaO0GFFsiqRinx4cc46bGCyhNnUoohKOkAFqscGNCGzs+a+l0xFsc4XiIGxMhJHFwwNzKZFgWFr18j6l+L6uGVFWfFlMK+eAsLEdtJ4Qa/59d5SGiGeAoBG9/XlYpa3pjSrnm9gAkLWzxeYJ8gLIeiS98Ff0UaKe4F04KrhTAOulJbGUWg7z4MYSrXYXxCT1jjy/ZQnZeLBYAKwXMMBab3hHEXptXdUm9NAWle8XAjN6niAybcX6PagJZyMmeCBKNTu/XN3Us6M5pQ+GdDxcGDA+xkh4BZe4edVu41tNMtsQkmWOfMRkYvE5AxRCkPa1fHYrN/ONmP0BvaHvR1BRaa/up6u3sQYbZv4bY78lOkq9wBStHh43W6LKN4F/GV4qCM3nkYzN1FU2xyecOqWWKDzYF1vI73Fa23nZvdHdmNRjN9IQm8YmGhOx/I4Y5hzISmBimeFzaE+iQG3ZYY5adrPNSqfEd83oac3YTsm/O41e9vP74uCaoARVvl2txxyhKantO3ipLJBOqJZGOQ7MTXB3F3+kBnc4Uvwnaue53bIBRr5Jmjzh/HNkKG6FYamShRhtDWOLeO/E= 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)(23010399003)(1800799024)(7416014)(376014)(3023799007)(56012099006)(11063799006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WDhzN3ZTVDQ0WVNMeSt4TGtQYmRzelRkSy9KT0dOcTFGRUkvQ2pMc1BGT0VE?= =?utf-8?B?MnJvUGtFTjgxanc5VXpBcDAzWFduZ1NneWJCYWdDeS90MytUVjgxRWNWL2wz?= =?utf-8?B?ODBXU1kwVnBSR3BaRElUelhtZkJ3YkVUWG8wUW9Gbkxyai9XMzlnTkU0bmNO?= =?utf-8?B?L2x6Qlg4bnV0ZEo5a0x3blVkZ3R2OWt5dUU5MGd5WGNqVStVaWFQYXVUUGlm?= =?utf-8?B?WW9VbURTRXdkcmp5TkUxeEhKZXNkNWRLYXVQblFxWVJWRjFOd0NjZkhWUS9s?= =?utf-8?B?bXFSRGF6UUxyY214TWQvV05XTXBNQkNPOXM3VTNqQzl4VENyeXhVSWpRL3dP?= =?utf-8?B?WURPeEpCQVZXSDBJd0JMQTk4TmwvTmV5dTdicHNZTnkveS9BWVlzR0FDUTRm?= =?utf-8?B?RlVBMWZhWnZrNHVLRFhNN0ZPQWRIZFBMU2ZOMHBjR2JNMlFpN1VLTUpCZUY3?= =?utf-8?B?RU0xSFA1Qis4Y0ZsU095RUE2Q3hyRmxpTmhMY0ZHdWVQdUFEQ3RiWEt6bTZv?= =?utf-8?B?U2RIVWVObzFObkhWWnp1RkhJazFmSStBVTBsWm9SdFo0ZU1yeVdTbi9aRzhk?= =?utf-8?B?eE9HUElHQ3VKK04rSnNVMGw2MHJSdUIrVFJwTi83aDFRa2ZtdmNFamtBVjI2?= =?utf-8?B?V2F6TUVjWm1PT1J3OFpJeDdwUm5qbFZpbUtxZmdlL1hpNGw1bDhSK1UyYmlq?= =?utf-8?B?bU9KWDNWalZzRzVmNDVZTERLT2xxM2xPR0xzclV3ZW0xUVhmUVZiZ0FmNU1O?= =?utf-8?B?UTh0elVJWWg2dVB3VGgyVFZPUGlVcWhFOWdDMVNhcjBEeDdlTld4YjFtWitJ?= =?utf-8?B?Qi8rZzR5T2RSMk5SOVB1cU5NUTR0a1d6Q1kwTzdsQVpiTzFBTFNwcG5ONnBv?= =?utf-8?B?MEs4amwrTW80NHF3anNNRmhmL09mQXBOUmpLMHhhZG15eWowUmgwWTBOTndI?= =?utf-8?B?ekdhcHRnSnR1V1p5NEJaL3UvYTlEaG1Ya2tycEpqbmwvL2dua2hWYlorVHdT?= =?utf-8?B?RlNRS2dzRVVBejAxVjlCd0RiTnZUTTkya0U4eG96NTYyc0lLd0Z2N3JCVGZm?= =?utf-8?B?QkhrUS9FZFA5ZEZzdWl2NHJGR3JYbG9rWGpqRjFoQ01vZXdGVU5pN1YwRmdR?= =?utf-8?B?cUUwa1JrVnM1ZndHNWN3VnQ3blMzekRxaUhVenNQTGo2ei9ENWRzdUxtV1dQ?= =?utf-8?B?SW1oVlFabWlTSklPRDBqMnVyb2VaNU44bTdjNk5YTjRFN2ZQdGxzVWV1bngy?= =?utf-8?B?RjZxWnJqN1JUeGZrcFBFaitCU2Z4WjI5ZThSS2NPR0V3MEY0c3BSSDBmVFJK?= =?utf-8?B?TDMxa3Y2UTNMRHA5SCtENmZYeGszUDM2U0J0cndPaktpRWFVQUYwV1huZ0xZ?= =?utf-8?B?UE1sUmMzRTg5ekdUeVQyTFRIRXVTd3E2VStVemJtaU9mZk8yMGhudUtYaDl6?= =?utf-8?B?NFVOcTRXT25HaGxrTDdSUXNhd1ZJRDBvTU5kb1NTQXN3bkN1SE41M3JIZUt3?= =?utf-8?B?bVBMejlIUWEvOVR1UUpKd0Z0blVSS3NpcW1EaHV2MUxJWHdvUGkzWms4ZTB2?= =?utf-8?B?YjJiRmxJSngyNlovS3ZNTVEzR0ZlbVczTjl0dm1DbkJtclk5VnBWRDZZekR1?= =?utf-8?B?cTBFa3FQcXdGT0pEU2NmV1JINzUweHF0VjFCL3Vaa3VkRGZxM0xBekJzTWIw?= =?utf-8?B?SFB0MHFPWkhKWUNpQ0xzRlQ5UkhyWDByV1BKdWJTRktLU21aKzllMlNEM3Na?= =?utf-8?B?QkRGUlFLc3hNdDEwb21RYkt0ZW55NFBTMzBsSU1YcEgvcGhmR2Y1VVVCOGg3?= =?utf-8?B?ZE5hb1ZJYXh6TDNwS2tMTFQyb2MyUDhYT2l2aVQ5WHBsYVZ5MkYvMzJEaXVp?= =?utf-8?B?Z0xjYkl1V25kd1BETVpSYitiR1lhQWZFODUwZDlFNVZpMXVUNkVuTHdaK05N?= =?utf-8?B?UEc5WG9NRDNQY1Z5UGw2SytaM0hvT0NHaDRGaVJ5V3lRaVZlU0FJSTdvKzN4?= =?utf-8?B?MCtNZktlM3JDdWEwMmhUWmhkR2N6NVJydm0wYTJYc2ZURWFwcVpXUmh1UlZG?= =?utf-8?B?QzNlS3h5MUx3TkpXRlFFTVNHOWZiaExFY2xTUlRQZVpqell5RE9TMUVvMXpo?= =?utf-8?B?NjdjUUtjTXNzSmt2K01NbCtwOWd5c1FOWktCeDIrdzhINmYrREtsVmdsUTZE?= =?utf-8?B?b3RiUmdYZEE2VC9lS1BJcnRWM3pjQUxZbHU3ZEJTVjUvcFZyWWRDOXMrd0t6?= =?utf-8?B?SDJBb0FLWG9XbldOeVdHSloxTGI1anZrblJDSHEzVHBPYUVONE8rQ0V3aXFJ?= =?utf-8?B?TlVxK2NRTGdiK01FN3NhSW9BZm95VUhUbG5UR01EKy9iMjBBVElqNHB6TGVh?= =?utf-8?Q?F+jqAyUI0CmQgwBk=3D?= X-Exchange-RoutingPolicyChecked: rC7Ymf0i6jajWAAbCjs2N88W8wbu7ME/jvqoT+v9My0+NTyaYXjkRqNcUIuoCtcmQFhm/qa2TeZu97ZSQtBYgE9h9E0Wpj9VLE5ZEUNxe8hZ9eZbQedYKZDQ8OiUQarbTFyNF9610uzOABepOQr4cMmOvBOCwDFTELqK+/0OWaaJmP4y/Hm6m2UbO+lZX5u+Zrzt/diD/9xqjF5hixVhVWDRrJIn/Tv0+IHPdKGTGX8+qprLCzuGOo/iwBJFm+R3IBGPld3KV+B/UuzfsoqmmflRHiItkH0vKmz16hKJiNGENYFqBqxpeZf8ia6RflOnm0nXeChJQ9xLvbGzMi1bFg== X-MS-Exchange-CrossTenant-Network-Message-Id: 19907801-49bc-463b-1398-08dee424371b X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2026 16:55:32.9275 (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: elBLzElkAVM6uZnMO/I2gTFGxH+9ZYdoVMlAUXE6nNfQP3/HwrSsHrOLZyhGPxbszPPNoz9SenG0kHn5upMvPrMjY8M5BES3wtgjGMksnT4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7531 X-OriginatorOrg: intel.com Hi Chenyu, On 7/17/26 9:02 AM, Chen, Yu C wrote: > Hi Reinette, > > On 7/17/2026 12:04 AM, Reinette Chatre wrote: >> Hi Ben, Chenyu, and Tony, >> > > [ ... ] > >>>>> Alternatively, could the "mode" file be used to switch between "MB" and "MB_MAX" and the two never >>>>> need be shown at the same time. The user opts in to using the new interface, "MB_MAX" by setting >>>>> "mode" and can just toggle back if they want to use "MB" directly again. > > Would this approach also work for region‑aware MBA, where a "mode" file is used to > toggle between "MB" and "MB_REGIONx_MAX", ensuring that the two are never displayed > simultaneously in the schemata? The goal is indeed for this approach to work for all features we are currently aware of. Please do point out if it does not. > > [ ... ] > >> RDT region aware when using MSR interface for legacy controls >> ============================================================= > > Do you mean there is a requirement to use the MSR interface when region‑aware > MMIO is available? My thought was that, if fine‑grained control(like MMIO) is > available, it would be good to always let the fine‑grained control emulate the > legacy one. resctrl makes no requirement to use MSR interface when region-aware MMIO is available. > And I'm trying to figure out the definition of "legacy controls": > Previously I thought that "legacy control" means using the existing MB interface > in the schemata to change the percentage value. That is to say, no matter whether > the underlying mechanism is based on MSR or MMIO, it is transparent to the > resctrl user. That is correct. > > For example, if the mode is "legacy", and user writes "MB:0=50" to the schemata > file, > 1. If that platform only supports the MSR interface, then it will be translated > into an MSR write. Or, > 2. If that platform supports MMIO access (i.e., the ACPI table is available), > we convert 50 into 50 × 255 / 100, and write it to the MMIO address. In this way, > the user still sees the "legacy" interface. The requirement here is that when user space writes, as in your example, "MB:0=50" then user space expects 50% bandwidth allocation. The underlying hardware MMIO control could be used if there exists a conversion from percentage memory bandwidth to the underlying hardware control value. I do not believe such conversion exists for all hardware that support the MMIO interface. Specifically, from what I understand, 50 × 255 / 100 in MMIO cannot be guaranteed to represent 50% memory bandwidth? On systems where such conversion can be made it is indeed possible to use MMIO for the legacy "MB" control. >> 1) System default >> >> info hierarchy >> -------------- >> info/ >> └── MB/ >>      └── schemata/ >>          ├── MB/ >>          │   ├── MB_REGION0_MAX/ >>          │   │   └── status:disabled >>          │   ├── MB_REGION1_MAX/ >>          │   │   └── status:disabled >>          │   ├── MB_REGION2_MAX/ >>          │   │   └── status:disabled >>          │   ├── MB_REGION3_MAX/ >>          │   │   └── status:disabled >>          │   └── status:enabled >>          └── mode:[legacy] native >> >> schemata file >> ------------- >> MB:... >> >> 2) User space switches to fine grained controls >> >> # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode >> >> info hierarchy >> -------------- >> info/ >> └── MB/ >>      └── schemata/ >>          ├── MB/ >>          │   ├── MB_REGION0_MAX/ >>          │   │   └── status:enabled >>          │   ├── MB_REGION1_MAX/ >>          │   │   └── status:enabled >>          │   ├── MB_REGION2_MAX/ >>          │   │   └── status:enabled >>          │   ├── MB_REGION3_MAX/ >>          │   │   └── status:enabled >>          │   └── status:disabled >>          └── mode:legacy [native] >> >> schemata file >> ------------- >> MB_REGION0_MAX:... >> MB_REGION1_MAX:... >> MB_REGION2_MAX:... >> MB_REGION3_MAX:... >> >> > > If I understand correctly, the "enable/disable" knobs are used to decide > whether to display this  control in the schemata file. If we make legacy > and native exclusive, do we still need the "enable/disable" knob? Indeed. If the controls are exclusive then the "enable/disable" knobs are not required to force them to be exclusive (but also see below). There may still be scenarios where controls need to be enabled explicitly and thus a need to keep the enable/disable knob. Here I am thinking about, for example, in MPAM that controls could be enabled/disabled (like MPAMCFG_MBW_PROP.EN for proportional-stride partitioning). > > On a platform where MSR/MMIO are both available: > > 1) System default > >  info hierarchy >  -------------- >  info/ >  └── MB/ >       └── schemata/ >           ├── MB/ >           │   ├── MB_REGION0_MAX/ >           │   ├── MB_REGION1_MAX/ >           │   ├── MB_REGION2_MAX/ >           │   ├── MB_REGION3_MAX/ >           └── mode:[legacy] native > >  schemata file >  ------------- >  MB:... > >  2) User space switches to fine grained controls > >  # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode > >  info hierarchy >  -------------- >  info/ >  └── MB/ >       └── schemata/ >           ├── MB/ >           │   ├── MB_REGION0_MAX/ >           │   ├── MB_REGION1_MAX/ >           │   ├── MB_REGION2_MAX/ >           │   ├── MB_REGION3_MAX/ >           └── mode:legacy [native] > >  schemata file >  ------------- >  MB_REGION0_MAX:... >  MB_REGION1_MAX:... >  MB_REGION2_MAX:... >  MB_REGION3_MAX:... > > Above looks to be where resctrl is headed at the moment. It may still be helpful to keep the "enable/disable" knobs to describe to user space when emulation is active. Specifically, when mode is "legacy" then there could be two region-aware scenarios: use MSR directly or use MMIO to emulate. Having the "enable/disable" knob will help to distinguish these two scenarios. Reinette