Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Message-ID: <26385423-6288-4f6c-b238-30c599250cdd@intel.com>
Date:   Thu, 7 Dec 2023 11:02:26 -0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 02/15] x86/resctrl: Remove hard-coded memory bandwidth
 event configuration
Content-Language: en-US
To:     <babu.moger@amd.com>, <corbet@lwn.net>, <fenghua.yu@intel.com>,
        <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
        <dave.hansen@linux.intel.com>
CC:     <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>,
        <rdunlap@infradead.org>, <tj@kernel.org>, <peterz@infradead.org>,
        <seanjc@google.com>, <kim.phillips@amd.com>, <jmattson@google.com>,
        <ilpo.jarvinen@linux.intel.com>, <jithu.joseph@intel.com>,
        <kan.liang@linux.intel.com>, <nikunj@amd.com>,
        <daniel.sneddon@linux.intel.com>, <pbonzini@redhat.com>,
        <rick.p.edgecombe@intel.com>, <rppt@kernel.org>,
        <maciej.wieczor-retman@intel.com>, <linux-doc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <eranian@google.com>,
        <peternewman@google.com>, <dhagiani@amd.com>
References: <20231201005720.235639-1-babu.moger@amd.com>
 <20231201005720.235639-3-babu.moger@amd.com>
 <47f870e0-ad1a-4a4d-9d9e-4c05bf431858@intel.com>
 <22add4c6-332c-45e4-ae0c-f287d6bff341@amd.com>
 <19e3fd3d-a2ec-4c8e-aa47-44f8f41b569b@intel.com>
 <ca471e43-b7ef-40f6-b0b3-3c79aa3a0d61@amd.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <ca471e43-b7ef-40f6-b0b3-3c79aa3a0d61@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R1Npay91ODF3bmRPRnE5VVhUcFJCUmpxWXR5blc4Y3VkUDJHNnpKQUh5cUE4?=
 =?utf-8?B?aExiTFVXN3dOYjI2c29qSzdwS09XdmNBemtlQ1l0SkJyUi9WK09MdnNkdTVz?=
 =?utf-8?B?bnBnZmR0RFNUZTJTS2lzL0U2Z0RSQ1pUSTBxOTd1MDVKWEZSV2VMT09nRlN6?=
 =?utf-8?B?VzRTMFZhYWxyaUxYU1I1bEsyb0pNcWszaW5uR3ducTBmdkhUeUNGL2kyNHZ3?=
 =?utf-8?B?dFpjQ0NmRFl4cURTZlBpNmkwM2RaRWx0WU9WRG52enV1S2k4ZHZ4MTJCdElD?=
 =?utf-8?B?YjdNN3kxQ1QyRFlGV09saXFoY3E1UXJTNkowTWE0Y0FPUFBVRDdYVnlqN0tY?=
 =?utf-8?B?SXRNQWExNXh0VUVtTDZOQnFQd2hVM1lyRHcwRUV4Yk5pNWdtakc4d1dhWUZx?=
 =?utf-8?B?eUcyQVFiRDNtUy82eFo2aXliNmlDa3NTSzI4Wi8zdFVXd1RjMkpHa3hLLzlF?=
 =?utf-8?B?UkdCcENJSTdkRVJjOFJVL2dpaEdZZUZIUE5SdEFoa1dhU29XZEc4Ull0TmtF?=
 =?utf-8?B?SFI3dFpxdnRJRG1nMHhpTW9sd25tK3J2TWYrTURzamtZdnFodWgxQVc0YWNa?=
 =?utf-8?B?UkxwdzRsdlBNU3pIRVJCeTBMcTJlWTlsby9oNzNzR3JVbnJDeEVocE1TQ2ow?=
 =?utf-8?B?RWlXeUNIeEw1OThYTVVNbHZhY1RUTkFNb2xjSE1oMk1XQ1NiRjNpTktDKzNn?=
 =?utf-8?B?OEV2Y3hCR1FCdEl2ZmlFUUIzenp0V1EreU01UDdvWEtwQlc0aEEwQzZidFZS?=
 =?utf-8?B?enZsYVF1bWZ3WlEyUUhSSTRwcFFBTE9wcDlBT0JFN1l4aGQ4QnR1bDhGTUJB?=
 =?utf-8?B?RjlXd0thYUJFWm9nWmEwS2pUYVNSNEFIc0pMREV2QkVtaEY5K3V3Ui9hQWYy?=
 =?utf-8?B?enpOOVZMMkgxaFlKdU9JQlUwdXhzaDkrRVdDNU5Xa3FweFNoaWEzY2tEN0tI?=
 =?utf-8?B?elVLZ3RUYzdWYmpoRVNhVWNtbFY2cHp6N0lsWDViNmpuN3ZIYmVLNkZ4aWo2?=
 =?utf-8?B?WWhGMFJBc2RTWXpOWHQrRXFTdlJjWlZQZlJ0YmZKTHRqZC8zTjQ3QlBJZWJN?=
 =?utf-8?B?NEk1WGRhMGUvTVR6RlFQSDdJZWM5OEtwTGJSTUM2ZVNjcG9LbVJVTFc5VjNz?=
 =?utf-8?B?SmFDT3h4ZDROemVucGpNYUYrZmhRYU1TRDZnZnBuRDF0WlFGMXVuVkRHemJV?=
 =?utf-8?B?aWM4YlFJYUZBdnFDRzBCZi9vVnE0TE5LVlFidVI3QTFnVkI4T29CbUovMEYv?=
 =?utf-8?B?Wm5wdG5iWmsyVTdvZ0U4TEV1eWRzc2VyZlRUS05tTDE0TGJIeGdlYXBVSjJN?=
 =?utf-8?B?T2l6bWRFajNIV0x5SVlYb0UzamFuOFBScTExWDdMQVU4VFkzbGJvazdTVUNu?=
 =?utf-8?B?YzlzYnBUdFgvcUZtcVFyWWdwVEh4SFMzbWdPOWJEaGYzb01LckxGVVZtaXRq?=
 =?utf-8?B?ZjFYWHZQeEVqQ0VaTDZ3a09jdCtYNUdmQmJYZjVoNmY1cFVJNWZHWGtwQ0F5?=
 =?utf-8?B?Zk9RaitFSWl1dExkd3RqSzcwdzh5cHNZOS9kQytHNDdMZTU5TUF6YTRvWCtr?=
 =?utf-8?B?VkdYeUMzNWFoVFp5QkdONmRUVTVlZ2g4MzlrV1gzcnUyZGpIM3ZyV25DK0w4?=
 =?utf-8?B?dXUyNlNhdzAzWWtOWSttdFBCUnNOTmdpMnlVbE9FTXFkYk1CWGptS2NDMmJ6?=
 =?utf-8?B?SXRPb1ZBWjZtN29IWjlzZTJ6YUhaL3Urak1EUTRtZkE2cksvRXFkU3QzNzlL?=
 =?utf-8?B?UTNVUUIvcVNQWUpzTFFBd3prK3NYSDl3dlJNczFtOFJGSENXcUZTYktoamls?=
 =?utf-8?B?NnRNZWNWU3loQ1BNUkRHZ0VGbmtZYzRod3lheHZxdjdPVGhCc2JqQU1zam90?=
 =?utf-8?B?UnNLVGoxVStYbTFPTzhkSmF0Q2FXYUl3MEZCMUpYSitPazlKTkVNMDN5RHJB?=
 =?utf-8?B?ZEZvT3FVSzVsazVoYjdnQmwrckJXVWd2cmh3QmkwbHN2d1JhRzBHQ1FzeWxB?=
 =?utf-8?B?OXIvVXVIR3NUdDVaanNRTG52VWdwZmtzdVRWa0tVU0ovYm5lNlpmMWkwWHhn?=
 =?utf-8?B?WWxHbmVsbURSZ1RPSlgrRnFFNkJVcFVHRHdWRWVNTE5CL2JaNENJMXNOaUZx?=
 =?utf-8?B?eUdKN0R1Z3RNVkFjS3l2YkFaSkZrTDlxUVEwYWgrbEFxMWd4Y0VPbDVUOXF3?=
 =?utf-8?B?bWc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 46c9c307-869b-4264-da0a-08dbf7570fc3
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2023 19:02:30.3788
 (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: oO1YL3qcyDd5or9IzHLNA9bGAzJAvFlicsxhovrx1lNFs5TiRrkIsYV7bXP61R8MwKIq5Nn0kiRrkxWQh6ke6OkbjIsdY646GuMW7dScrmc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5487
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 07 Dec 2023 11:02:49 -0800 (PST)

Hi Babu,

On 12/6/2023 11:17 AM, Moger, Babu wrote:
> On 12/6/23 12:32, Reinette Chatre wrote:
>> On 12/6/2023 9:17 AM, Moger, Babu wrote:
>>> On 12/5/23 17:21, Reinette Chatre wrote:
>>>> On 11/30/2023 4:57 PM, Babu Moger wrote:

...

>>>>>  static void mondata_config_read(struct rdt_domain *d, struct mon_config_info *mon_info)
>>>>> @@ -1621,7 +1621,7 @@ static int mbm_config_write_domain(struct rdt_resource *r,
>>>>>  	int ret = 0;
>>>>>  
>>>>>  	/* mon_config cannot be more than the supported set of events */
>>>>> -	if (val > MAX_EVT_CONFIG_BITS) {
>>>>> +	if (val > resctrl_max_evt_bitmask) {
>>>>>  		rdt_last_cmd_puts("Invalid event configuration\n");
>>>>>  		return -EINVAL;
>>>>>  	}
>>>>
>>>> This does not look right. resctrl_max_evt_bitmask contains the supported
>>>> types. A user may set a value that is less than resctrl_max_evt_bitmask but
>>>> yet have an unsupported bit set, no?
>>>
>>> I think I have to make this clear in the patch. There is no difference in
>>> the definition. Hardware supports all the events reported by the cpuid.
>>
>> I'll try to elaborate using an example. Let's say AMD decides to make
>> hardware with hypothetical support mask of:
>> 	resctrl_max_evt_bitmask = 0x4F (no support for Slow Mem).
>>
>> What if user attempts to set config that enables monitoring of Slow Mem:
>> 	val = 0x30
>>
>> In the above example, val is not larger than resctrl_max_evt_bitmask 
>> but it is an invalid config, no?
> 
> Yes. It is invalid config in this case.
> 
> How about changing the check to something like this?
> 
> if ((val & resctrl_max_evt_bitmask) != val) {
>                 rdt_last_cmd_puts("Invalid event configuration\n");
>   		return -EINVAL;
>    }

This would address the scenario. I also think that it will be helpful to
print the valid bitmask as part of the error message. The original implementation
specified that all bits are valid and in doing so no interface accompanied the
feature to share with users what the valid bits are. The only way user space can learn
this is is to read the *_config files after the first resctrl mount after a system boot
to see with which config values the system was initialized with (assuming system was
initialized with all supported bits enabled).

Reinette