From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazon11010068.outbound.protection.outlook.com [52.101.61.68]) (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 8ABA730C173 for ; Wed, 3 Jun 2026 01:14:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.61.68 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780449253; cv=fail; b=PdTgNqzowu22TF/iTOPg+PA2yo8XwhBG+dLmZAHnJuSw/OTGjXFphtgQUHtfopFM/uDyHKYD5AR7jWNjdAe3/2bZVe/atz3zJS7JCCbWP9NuATTy32tVarykiNXL5r2dP7ehf10aAL43GoFqm+EJKDv3Qt+sh42rHbisKs61Eiw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780449253; c=relaxed/simple; bh=gNNTp5CQRi7/Te9YbI+/EGOLmvO1NgvqOyvnnTQRewk=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=tPn6ChkBwzkihtWS1oVR7lqWX2GMEQC9n9hkzkLnP7DnUdDq04J5FBhNpn5aKtL89xwtGc61DXM2bn6AK5bnALMSfZr7OJBGwFq2hx0jsdiH49/JArVmEeCISUdnZGlRw0ecVpOHGYekKUQNfXl2jNmUpQp1J/HcpCpl4Eno1Xs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=GGvEiO2D; arc=fail smtp.client-ip=52.101.61.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="GGvEiO2D" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PXKJkWaNZAbPgUymXa0AZiDC4RTdUC1jhquYzY8msF3bsVEkWDst7+itoLGg2p6IDbcd+o3kaoS6+eLz6kBV4k1DU5Z2ScKIEHZmM+FBQDXzbqqVXGS5cFRtzJcO/3F0sic4RrtN1yimsEJ/Wx2C6BlqVX/tA5jyQs5/9NM/0HRxCEaiR5Ifx2MxwvDkVGNYPeoI4vkSrzbt0baXG9QtQ+uCLwpBqdIcghIVQT4BgqVxSUrLrxtrucAsq3UVKtOa/p164lhG/A0f/xdVnasGKdD3K+MofDpB6KrOmIKIhz5cXgcfwuyeQlEbQNbOkniepKvUGvr8EM08jjmB1jspGw== 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=4M8ft38uhYAkEhwsqaIO7lc+cYbsvvcO7opJrqu3/iA=; b=s1DEfZmUE0RI3caWFpfO4iOy58ksY/B5MfnzcemGaFs8SGf3UYtpsz9M01tiqZdU2I9JK09zOTDlQ/4lfwMrorM+bBY1a+UkXrfxKWrf2KqcBTovWqrcVaztOyQq9+NYrJk64JgQpt7sewcuU636QOFi1GiZvNJu4thRfQbg50N4yresNDaq6i5+YBjKXDL83CFxc7f+8iWy1O8F4ICI/9fbWKIIkttbKbeJriVgRg2YN22yV67Eb4kPSsQj8cTIeliz+Ux/T+m+cQf6xsnUi3EkWZfj0vIlZ4vaBfW8k1niYjoqWG2unI56GMKX+zOBgbmekC2DFXuWa+GDQTs2oQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4M8ft38uhYAkEhwsqaIO7lc+cYbsvvcO7opJrqu3/iA=; b=GGvEiO2Dn66zc9SxbexG/S/U08CFcZrKlzGzStdbNyfyaIJj5Ib+z1koTEscBwAN2qktgjw2joISFr7cq9LJ9r9mX5fJWejc622nCfKYL0DqPo/izHMfjTENCXUGW52LtZrE70iOTi47pyHSPiVcEqxpV7OfSBq72qUTWT3qe24= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from BL1PR12MB5320.namprd12.prod.outlook.com (2603:10b6:208:314::17) by CH3PR12MB8659.namprd12.prod.outlook.com (2603:10b6:610:17c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.71.15; Wed, 3 Jun 2026 01:14:08 +0000 Received: from BL1PR12MB5320.namprd12.prod.outlook.com ([fe80::1876:4a6d:2cf5:b8d1]) by BL1PR12MB5320.namprd12.prod.outlook.com ([fe80::1876:4a6d:2cf5:b8d1%5]) with mapi id 15.21.0092.006; Wed, 3 Jun 2026 01:14:08 +0000 Message-ID: <81f27656-2c56-4419-95cc-54424592c1e7@amd.com> Date: Tue, 2 Jun 2026 20:14:05 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , Babu Moger , Tony Luck , Ben Horgan , James Morse , Dave Martin , Drew Fustini , Fenghua Yu , Chen Yu Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <188147f4-db82-4aa6-adb0-d1a26565cfdd@amd.com> <533f6b30-6d6d-4962-a7f5-b7b83d888f6b@intel.com> Content-Language: en-US From: "Moger, Babu" In-Reply-To: <533f6b30-6d6d-4962-a7f5-b7b83d888f6b@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: CH0PR03CA0342.namprd03.prod.outlook.com (2603:10b6:610:11a::16) To BL1PR12MB5320.namprd12.prod.outlook.com (2603:10b6:208:314::17) 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: BL1PR12MB5320:EE_|CH3PR12MB8659:EE_ X-MS-Office365-Filtering-Correlation-Id: c51a42e0-a25e-4264-0f37-08dec10d694c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|22082099003|18002099003|5023799004|56012099006|4143699003|11063799006|3023799007; X-Microsoft-Antispam-Message-Info: Z/ULXlAZWCyaapReov7ypLCDis8IyTSP/MXIvN2YOHGSCdcCwBORVhnwW/CGVt+ZhM+GZwtpdU/ycn8TIWU0k2DdMOQqw9uv10jIJ/n3uvXIA/FYwN4YtGp1YkW7Q/GSXO66rCqO9aK9hPF94N8gPDOTINX+MtBhh3T1BPVzfyQkOywP/ege+8ZL44GC5SFkUq/f8mIH7g9uE75qiDawWK92JUPVFq7dBQJFy7lTidAHy3AAOxoucepyZNilTB/zxDW1rNgGjUBABzNoC+F07nq7O1/j8SVCfZF6HgtTFPpIXFtpd+8k2Bqz9jmaDDAF1n72BYmht9rfWN+f0bI3dnUyZzhRNh8Qsh3sSxE859mO3xb/p/zxSiJnnEfZBkVfs/mu0yrCocdCDtPgbaAYh/s/czttx8DhHlxDhz/os4oGCekjjUjjqBddzKzAVoMIUJUhptthxFhPloAf7zFtMv+pxDL7svACc6jWykvIIYcL5ZGC8Gm6/sxS2P9xC2enPtnDUCtvHS78ew+wybHaTv2eVPWoFwhWA9vaiMyWvaada6EUa8SD2m6Qlx0iAfBZu2OfSE/yRPAuX8EZj0b6TUs4rN4GWWiB+zQK7un+37tJpxwWYhhjOBIiFdCg+T7fpRYhvmSYqqjUI/IARM9vuA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5320.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(22082099003)(18002099003)(5023799004)(56012099006)(4143699003)(11063799006)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZExUTFNJZkF3R3R0UFpndytSb2pmVVhac3pRRXlSNjlsWmxKZ2E1TUFQVldX?= =?utf-8?B?c3k2NDNuL0FPNXRYa0s1NGxsVW5FUzNjdE1jTlY1UzIveHlURDErV1NDOHZI?= =?utf-8?B?d2V3SEp5bFhLUDBRNnBpdzJjYXJHU043MUZFdmlQUE5QWFh6d0FJWk14c1lY?= =?utf-8?B?MnJBSnhwZkhjWUhFamRpTFZBZ2pOaU9Ec1BITEpWdkRBdXlGU0FxeFlpOUl1?= =?utf-8?B?YXBIUzlIY3Y0UTlSU2Z1Zm9hZk1Xdis3R0ZoNW8rRnpZaGFFSmlCM1M5VjVx?= =?utf-8?B?S3pTVE9QZS9BS0JKQTJ2L1RMcktPNEhDaVl2QjR1L0EyNHBnQVB3QnRPb1Yz?= =?utf-8?B?ZXAydHFhRzVwQUsyRUp6T0xhUTdSVnduTUhGNGFGNC9qZDhtb3ByUi85c3pu?= =?utf-8?B?aXNRRjZnMm5ZWjBTalVhS1ZXazZsNW9aWDk2WEZ3aFVvdGQ1Uk9ERjIybmtQ?= =?utf-8?B?MmQ4cDlvb3hmdzUwVVYrcFVPVmRQbmxTcWZMR21sRTFIM2pEWEdjbW1Qc3R4?= =?utf-8?B?UlJxL042RldNeG9TRWYrV21iMCtwcnY4bEVxa0luWlo1THErdDlOdFUzZmM0?= =?utf-8?B?WitDRDNuRFFrWUpOREtkRUxhZjNMYkZwUWpBSjA4M3VzSm1zWHFtbGg4K2xa?= =?utf-8?B?bStmcldNNGFlWGdCRWFiemlHdkYxcmlVelJGRmNob2FTSkFSSnNoVHpSc2Z6?= =?utf-8?B?TG54MzNGTzBUajF3UE91Nlp1RC9zbFZIOXR5Q2tUSjFmdk1jZVNqZkFIM1NC?= =?utf-8?B?b2JLSk9KcHlIOWxZTnRSWmNxdkUwb2tINDNGRkt4RVZZNXI0UHNhckFCaFpU?= =?utf-8?B?dUlFUXFiZ1IzNlpWMGtNUjJJOHJ3Z3QyYXRZVlFUQWppOG1IZVhYVVFwRElt?= =?utf-8?B?blpSWjV1MFlwS3h4eGpaM2U4L0F6RTFkOHBselcxcXByVUFZMnlEWUZkakpU?= =?utf-8?B?cHVyN1dFRFppWFljUHpOSm1iL1dQMmw4SnRZT0g0N3FOcEdia0VDQVlVb3k2?= =?utf-8?B?QUVxVnBnU1hLYzRONkZmclNJUWUwd2xzSHBjWURxVnJQdDQzalluVENQNzdZ?= =?utf-8?B?ejU3RHhYRmZoUUxCalgwWkxjZ0JPUnRmKzhMT1Q5UDRKbjI3RVR6UlZLTFpy?= =?utf-8?B?WnlhbWxWcTFWR1ROY0NnS0I1U2RrQWJJZ1VJK0FhNXR4S2hrZXZtblpnMWpJ?= =?utf-8?B?VTRoWjBDWkxka2RoN2Q5UWhUVG5uN3RRVXpUd3p0MXV5a0tkbHhCemRtU045?= =?utf-8?B?V1pDa3BrMWo2WlQ3TkdISUFpOUkweUFPUkxVQ2lJOUxySll4WmV1YURQWVVa?= =?utf-8?B?RWNOYk95dEV1NDI1U096Z3M0bmdIQnhyTXBJdVJ1amt6NWVCand2VkhEYUVk?= =?utf-8?B?TUlIL21nNGFOYmtGMEJ4VSttQ3NFZUt6NnBEY0Q5ditRMWE2Y3IrWVd0c2J4?= =?utf-8?B?cHoyVU1kWGRZYWZFUzZtVWVkNGQ1NVdNM2RrSkFId2FkTG1GUXZMNkx3cUtr?= =?utf-8?B?UTJBTFNza09HSUs2Q0lPd2s4MlIwU1M3cUF5dnFucUJtVkxJWHRMR2xGQUVM?= =?utf-8?B?dkQ5UjBwRElPc0hZbENpd05QYlJqWStYeVNreU4wOGJoVmxwUTNQc0FZU21C?= =?utf-8?B?SjNNa2Rybmhhb00zTVFPSFhxUGZqbVFIVi9ObUtjOVNvNWgzUUx3MUlJMm5p?= =?utf-8?B?N2QxbGlpWW5DTUw4bE40cVhXLzNtVWh5ak9tS1JCVEdlYWdCMkNGVVdyak1N?= =?utf-8?B?bWNZRFVUVVQ1d3hsTmRCQkg5YnRVOWYzV2s3MVhMaXRsZWk4ZDdIWWRkQUd2?= =?utf-8?B?dWh0dWdDaXFNcm5xK2tLNUxPWVhQcTkrM2ptU2srODdTK0d4U1J2M3MrZGtD?= =?utf-8?B?VnU3UXRSYWkwR0E0OVVRYnlXcVV0Qnl0cWdibkQxZ1JpUUFxTHphbWx5Q2ps?= =?utf-8?B?NnBJL2h5YUFGYVB0RHVML0JjbGhuTFFaSEVQb0dMRTgvdmxMU1VSeUU1eHlr?= =?utf-8?B?MW53RGIvaXpUaWJSaStFb1dIa1hZbUJVVkN4RU9ZVVJCcEN2S0xyRGI0dEdR?= =?utf-8?B?MU1CdGNiUVZWR01yai9jd1o2UTJESWh0bW9GUnVEdmxOUHRxUXN6NWlwZTRi?= =?utf-8?B?MUc1aWNzZkhlZW1haWNnZnZ6dUdwaVR5VzBvY3FNQWdsUXdxZVFsQUZNNWhT?= =?utf-8?B?Z0wyWnZnak84MW9rTko2citNdzgzYnd4NDRIaER1R0JwNTFybVl2NmMxSmJj?= =?utf-8?B?NHd4aW8wY1FvK1ZTdTlMcEo1SHovSlExUjJjZVpZZHFqdWFqSXY4UnlKQ2Zu?= =?utf-8?Q?AURe/Wsrt2egBuBYSJ?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c51a42e0-a25e-4264-0f37-08dec10d694c X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5320.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2026 01:14:07.9394 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4LkFWEm/Q9+wIKnHxZksRkt5eEYRHhzLd/mL//CsvkN4btB9kIC2ojmFsKS0n/JU X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8659 Hi Reinette, On 6/2/2026 5:56 PM, Reinette Chatre wrote: > Hi Babu, > > On 6/2/26 1:23 PM, Babu Moger wrote: >> Hi Reinette, >> >> For some reason, I couldn’t find your patch on lore.kernel.org: >> https://lore.kernel.org/lkml/?q=Reinette+Chatre > > How about: > https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ Yes. It works. But, I used to find patches using the names. It did not work this time. > >> >> I eventually located it here: >> https://sashiko.dev/#/message/aab804b9-e8b5-40ad-a85b-af7033391243%40intel.com >> >> Thanks for sharing the patches. I’m still reviewing them. >> >> I was able to build and boot the kernel and can see the MIN and MAX controls. After moving your test code to __rdt_get_mem_config_amd(). > > Thank you very much for trying it out. > >> On 5/29/26 13:06, Reinette Chatre wrote: > > ... > >>> Primary resctrl fs data structure changes >>> ========================================= >>> >>> Introduces a control represented by struct resctrl_ctrl that looks as below. To make >>> the changes easier to follow I kept some of the original names to help communicate >>> where familiar data structures land. >>> >>> What to notice about a control is that it has some common properties required >>> from all controls (scope, type, etc.) and then depending on the type of control >>> (RESCTRL_CTRL_BITMAP or RESCTRL_CTRL_SCALAR) there are type specific properties. >>> >>> /** >>>   * struct resctrl_ctrl - A resource control >>>   * @entry:    List entry of rdt_resource::controls >>>   * @scope:    Scope of the resource that this control allocates >>>   * @domains:    RCU list of all control domains >>>   * @type:    The control type that determines the properties of the control, >>>   *        format string for displaying control values to user space, and >>>   *        parser of control values provided by user space. >>>   * @name:    Name of the control. Appended to final resource name >>>   *        (rdt_resource_final::name) to create final schema entry. >>>   *        Specifically, "rdt_resource_final::name"_"resctrl_ctrl::name". >>>   *        For example, with resource name "MB" and control name "MAX" the >>>   *        schema entry will be "MB_MAX". >>>   * @cache:    Cache allocation control properties. >>>   * @membw:    Bandwidth control properties. >>>   */ >>> struct resctrl_ctrl { >>>     struct list_head    entry; >>>     enum resctrl_scope    scope; >>>     struct list_head    domains; >>>     enum resctrl_ctrl_type    type; >>>     enum resctrl_ctrl_name    name; >>>     union { >>>         struct resctrl_cache    cache; >>>         struct resctrl_membw    membw; >>>     }; >>> }; >>> >>> Two members summarize how this new structure fits into the rest of resctrl: >>> a) resctrl_ctrl::entry >>>     Since a resource can support multiple controls there is a new list >>>     in struct rdt_resource named "controls" that contains the list of all >>>     controls supported by the resource. >>> b) resctrl_ctrl::domains >>>     Instead of the list of control domains belonging to a resource they >>>     now belong to the control self. By doing so resctrl can support resource >>>     controls at different scope for the same resource. This is intended to >>>     support some upcoming MPAM and RISC-V usages. >>> >> >> I like the idea of supporting multiple controls for each resource. >> >> With these patches, now we have one list containing all the controls. >> >> However, in case of RDT_RESOURCE_L3, we have two lists "mon_domains" and "controls". mon_domains list deals with monitoring and control deals with control parts(multiple). >> >> Have you thought about making the list("control") generic so that the control can be monitoring also. It will just one list containing multiple controls or monitor. > > The control list adds an additional layer of abstraction just for control management, > independent from monitoring. The mon_domains list is unchanged while each control now > has its own ctrl_domains list. > > Here is an attempt to visualize how a resource with two monitoring domains, and two controls, > each with two control domains end up being managed: > > +-------------------------+ > | struct rdt_resource | > +-------------------------+ > | ... | > | controls (list_head) |---------+ > | mon_domains (list_head) |---+ | > | ... | | | > +-------------------------+ | | > | | > +---------------------------+ | > | | > v v > +-----------------------------+ +-------------------------+ > | struct rdt_l3_mon_domain #1 | | struct resctrl_ctrl #A | > +-----------------------------+ +-------------------------+ > | rdt_domain_hdr |-+ | entry (list_head) | +----------------------------+ > | ... | | | domains (list_head) |------>| struct rdt_ctrl_domain #A1 | > +-----------------------------+ | | ... | +----------------------------+ > | +-------------------------+ | rdt_domain_hdr |---+ > +-----------------------------+ | | ... | | > | (next) | (next) +----------------------------+ | > v v | > +-----------------------------+ +-------------------------+ +----------------------------+<--+ > | struct rdt_l3_mon_domain #2 | | struct resctrl_ctrl #B | | struct rdt_ctrl_domain #A2 | > +-----------------------------+ +-------------------------+ +----------------------------+ > | rdt_domain_hdr | | entry (list_head) | | rdt_domain_hdr | > | ... | | domains (list_head) |----n | ... | > +-----------------------------+ | ... | | +----------------------------+ > +-------------------------+ | > | > +----------------------------+ > | > v > +----------------------------+ > | struct rdt_ctrl_domain #B1 | > +----------------------------+ > | rdt_domain_hdr |---+ > | ... | | > +----------------------------+ | > | > +----------------------------+<--+ > | struct rdt_ctrl_domain #B2 | > +----------------------------+ > | rdt_domain_hdr | > | ... | > +----------------------------+ > > resctrl used to manage single domains that are capable of both monitoring and control > but this was split to support scenario where monitoring and control of a resource are > done at different scope. See > cd84f72b6a5c ("x86/resctrl: Prepare for different scope for control/monitor operations") > > This feature further expands the difference between monitoring and control since now there > can be multiple instances of a control domain (one per control) associated with a resource > while monitoring still just supports one monitoring domain per resource. > > I thus cannot see how this can be accomplished with a single list. Could you sketch out > what you have in mind? > Thanks for the sketch. It makes it much more clear. mon_domains directly maintains a list of monitoring domains, whereas controls maintains a list of control objects, each of which owns its own domain list. I was thinking, one possibility would be to make mon_domains follow a structure similar to controls, allowing both to be represented through a common top-level list. However, the resulting abstraction may become fairly large and complex, with limited overlap between the monitoring and control data structures. > ... > >>> >>> Patch 54: >>> Teach resctrl fs about "MIN" and "MAX" controls. >>> >>> Patch 55: >>> Sample of "MIN" and "MAX" memory bandwidth controls for x86. >> >> My assumption is that the MIN and MAX controls here are just examples, correct? >> >> You only mentioned patch 55 as "NOT_FOR_INCLUSION". I assume patch 54 should also be marked as "NOT_FOR_INCLUSION"? > > While patch 55 is the first and only "user" of patch 54 I believe that patch 54 (or some variant > of it) will stay since we already know that both MPAM and Intel need to support min and max controls. That is good to know. Thanks Babu