Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Mon, 20 Nov 2023 11:48:06 +0100
From:   Maciej =?utf-8?Q?Wiecz=C3=B3r-Retman?= 
        <maciej.wieczor-retman@intel.com>
To:     Ilpo =?utf-8?B?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>
CC:     Fenghua Yu <fenghua.yu@intel.com>,
        Reinette Chatre <reinette.chatre@intel.com>,
        Shuah Khan <shuah@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        <linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH] selftests/resctrl: Add non-contiguous CBMs CAT test
Message-ID: <ilacrcz7o6wq2zdl3szb3cpkkboo43t3t2oyk4cmv3iwarstkj@kk34x5q4fpas>
References: <20231109112847.432687-1-maciej.wieczor-retman@intel.com>
 <879955f-d2d4-017-6694-5a031ec7f2@linux.intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <879955f-d2d4-017-6694-5a031ec7f2@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?UbBoHcSNCANt8kPdgRcMX0GI10pNGS1pTEAdmnKq02mNi+R3gAbmZpxDvh?=
 =?iso-8859-1?Q?aEk7Jrz9lNtAnisdaxDYlm8/1cfvxRxq3cOJ9mzRmU0dOgM+xeIHv9BVqi?=
 =?iso-8859-1?Q?7rCYCX5n9ODrUOwpN3XXY8TrORhFfBotcQspQFh0i9qpsD+DsuhO0WfhDB?=
 =?iso-8859-1?Q?apBljolR/LtICwlBIRzp+Hl7pTOvzQcTXU0EusBjqlfKzIo5FA4/qvkjGs?=
 =?iso-8859-1?Q?1kj++OufKCRqhrXe7D8955MTPX0at+JSieKHCHgbCUvjINCJdMy5K+O9L4?=
 =?iso-8859-1?Q?NeGea/sB9NYjjhOrSxYAyTBXGVdHFibCGd42VeCI82z1oZiu3KVE9KSsSs?=
 =?iso-8859-1?Q?LhHl6bxU+IeW8mrvvHFD/FsKsyW9VG1YstnL6gWOmE+/tmA+sjPbDs75x8?=
 =?iso-8859-1?Q?/CyxlZA665GFSXwbjLDbWGMhgM0JfZ1h9GVLD0psDjRy/nHFuz1vBGkfpL?=
 =?iso-8859-1?Q?iqMgvD8Swqh2c7ldN6mN57dBWvzu/JEit7ZCt46eHE4l1oufjeXiqs/xEu?=
 =?iso-8859-1?Q?w1tSjYdqizChd7AIqcuzC5/+rDDRhSwhdBtSnchLGENP5gfe4OqYVBukVK?=
 =?iso-8859-1?Q?QyWUOCRg6uhFvhFnaCdj+7DJttbYzlqGgxntZCSdbCN5/ww4Uz+f2YYp7s?=
 =?iso-8859-1?Q?uemcrgnOlQsZ+kP95hh2+7MfJ0JvPBVzNKMGtA41p08FHwnR0yPvIklAFo?=
 =?iso-8859-1?Q?+F4oQpsweo0OEgL7pV8J9xzVwlqpyD+7xMbmU9jcEqNMbPT0zkkTRIJxxP?=
 =?iso-8859-1?Q?J137kZcX6CkdkAmphOdablz7bseFRFKhHjC3Au9fqRBcVUt/Th1Ldb1j0s?=
 =?iso-8859-1?Q?O9osqUEG9ujYn2OTgoaSeAQu10MwuwMDHCJ/yNLVeDSFNCUgqGEMdLbWU1?=
 =?iso-8859-1?Q?5Dlo1VW/9m2ZXxiX3fhQvtCl8j/4/vTJ5Ft/eUH55DTCHEZhq66djGGT7M?=
 =?iso-8859-1?Q?o4X9h1rK+Qtfp649ySceVwATDHsyy2+8F3r0APhL0eHIWQv1MqR83LPpRN?=
 =?iso-8859-1?Q?gSoPn96/ZgNSduCBcyMpcpgb64eVZmMqrrcPZD+tJ+OIhpcIBYv9tMjfVr?=
 =?iso-8859-1?Q?hNlPzXYsWeIOvYjCFBv2CH87Gvgv1L67zM2YRvjZk2GVaYOXKamIj2Gcb0?=
 =?iso-8859-1?Q?DyAwpmL4pRpdS8pKrKZCTjNPnGceEZQYZMloeB3ZjST3oyq/CocYBmp6d6?=
 =?iso-8859-1?Q?VO07vkn+PeXIYlxHT0akKm9BDEAZVZC6E0Z4VWj8/d8mkSVYh20N4RxwUJ?=
 =?iso-8859-1?Q?NHpNbgcXkaAzWBg4fXd924xEYBn1zGR4Kz2DNN8Y0Q/ANYVGZ7+9p72yy4?=
 =?iso-8859-1?Q?8cNBMdQZZ1tNEMPeCJMfP1CCb5ypsETAN/RfsQ6LXMaHGHZZXIB5CBElPw?=
 =?iso-8859-1?Q?qxkyvlRoVb6JfsnuS2Z9mvyKbInLDAiyziafdqOnbouUkP3UwC6zVNh2Tb?=
 =?iso-8859-1?Q?bjVvxd40wof3A8YdxWKMb8Q1yqwdA3oa3Eezc3GjND23dkZ20fXZHLEKf9?=
 =?iso-8859-1?Q?ABl171cknplNelxeEqvQbGeBbEtDh8SucRXu2961/3G3Y1sOazEEtrdLBW?=
 =?iso-8859-1?Q?1pLFEPd7jtOKp6107L0fZIpV3gPN7T5w36k1mFBeR3W7aiwECX39JCh/9A?=
 =?iso-8859-1?Q?V28Ro0Z4I/7APzcfZv75enxHNMJ1dOQOfM9lRocqAw1C5C0Dj5KqYhXYtD?=
 =?iso-8859-1?Q?V0kcas+fWg60zCxYnfo=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: d637f5a7-736e-424e-affd-08dbe9b6301a
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6231.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2023 10:48:10.5201
 (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: IyWZlEzT+v6D0mtammZbnV84DlNQG/exo6abhy7t2t13EQMkhwVTeElnwXx6jzS1PuzccOa0iB3iyaJbAVBA0feDn+dviaUL8fQCWj8KVJU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6611
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 groat.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 (groat.vger.email [0.0.0.0]); Mon, 20 Nov 2023 02:48:58 -0800 (PST)

Hi, thank you for reviewing my patch!

On 2023-11-17 at 14:55:54 +0200, Ilpo J?rvinen wrote:
>On Thu, 9 Nov 2023, Maciej Wieczor-Retman wrote:
>
>> Non-contiguous CBM support for Intel CAT has been merged into the kernel
>> with Commit 0e3cd31f6e90 ("x86/resctrl: Enable non-contiguous CBMs in
>> Intel CAT") but there is no selftest that would validate if this feature
>> works correctly.
>> 
>> The selftest needs to verify if writing non-contiguous CBMs to the
>> schemata file behaves as expected in comparison to the information about
>> non-contiguous CBMs support.
>> 
>> Add tests for both L2 and L3 CAT to verify if the return values
>> generated by writing non-contiguous CBMs don't contradict the
>> reported non-contiguous support information.
>
>"if ... don't" sounds weird to me. Perhaps the "if" could just be dropped 
>from it.

Thanks, that does sound better.

>> Comparing the return value of write_schemata() with non-contiguous CBMs
>> support information can be simplified as a logical XOR operation. In
>> other words if non-contiguous CBMs are supported and if non-contiguous
>> write succeeds the test should succeed and if the write fails the test
>> should also fail. The opposite should happen if non-contiguous CBMs are
>> not supported.
>
>To me this sounds a bit verbose given how basic thing it talks about 
>(but maybe I'm too old already to have actually come across a few xor
>tricks in the past :-)). I'd simplify it to (or simply drop it):
>
>Use a logical XOR to confirm return value of write_schemata() and  
>non-contiguous CBMs support information match.

Your version seems sufficient indeed. I didn't want to leave that XOR in the
code without any explanation.

>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> 
>> ---
>> 
>> This patch is based on a rework of resctrl selftests that's currently in
>> review [1]. The patch also implements a similiar functionality presented
>> in the bash script included in the cover letter to the original
>> non-contiguous CBMs in Intel CAT series [2].
>> 
>> [1] https://lore.kernel.org/all/20231024092634.7122-1-ilpo.jarvinen@linux.intel.com/
>> [2] https://lore.kernel.org/all/cover.1696934091.git.maciej.wieczor-retman@intel.com/
>> 
>>  tools/testing/selftests/resctrl/cat_test.c    | 97 +++++++++++++++++++
>>  tools/testing/selftests/resctrl/resctrl.h     |  2 +
>>  .../testing/selftests/resctrl/resctrl_tests.c |  2 +
>>  3 files changed, 101 insertions(+)
>> 
>> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
>> index bc88eb891f35..6a01a5da30b4 100644
>> --- a/tools/testing/selftests/resctrl/cat_test.c
>> +++ b/tools/testing/selftests/resctrl/cat_test.c
>> @@ -342,6 +342,87 @@ static int cat_run_test(const struct resctrl_test *test, const struct user_param
>>  	return ret;
>>  }
>>  
>> +static int noncont_cat_run_test(const struct resctrl_test *test,
>> +				const struct user_params *uparams)
>> +{
>> +	unsigned long full_cache_mask, cont_mask, noncont_mask;
>> +	unsigned int eax, ebx, ecx, edx, ret, sparse_masks;
>> +	char res_path[PATH_MAX];
>> +	char schemata[64];
>> +	int bit_center;
>> +	FILE *fp;
>> +
>> +	/* Check to compare sparse_masks content to cpuid output. */
>> +	snprintf(res_path, sizeof(res_path), "%s/%s/%s", INFO_PATH,
>> +		 test->resource, "sparse_masks");
>> +
>> +	fp = fopen(res_path, "r");
>> +	if (!fp) {
>> +		perror("# Error in opening file\n");
>> +		return errno;
>> +	}
>> +
>> +	if (fscanf(fp, "%u", &sparse_masks) <= 0) {
>> +		perror("Could not get sparse_masks contents\n");
>> +		fclose(fp);
>> +		return -1;
>> +	}
>> +
>> +	fclose(fp);
>
>Add a function to do this conversion into resctrlfs.c.

By conversion do you mean the above calls to fopen, fscanf and fclose? Or did
you mean the below __cpuid_count? Since you mention making get_cache_level
non-static I assume the first is the case but just wanted to confirm.

>> +
>> +	if (!strcmp(test->resource, "L3"))
>> +		__cpuid_count(0x10, 1, eax, ebx, ecx, edx);
>> +	else if (!strcmp(test->resource, "L2"))
>> +		__cpuid_count(0x10, 2, eax, ebx, ecx, edx);
>> +	else
>> +		return -EINVAL;
>
>This would be same as (you need to make the func non-static though):
>	level = get_cache_level(test->resource);
>	if (level < 0)
>		return -EINVAL;
>	__cpuid_count(0x10, 4 - level, eax, ebx, ecx, edx);

Thanks, that does look tidier.

>> +	if (sparse_masks != ((ecx >> 3) & 1))
>> +		return -1;
>> +
>> +	/* Write checks initialization. */
>> +	ret = get_cbm_mask(test->resource, &full_cache_mask);
>> +	if (ret < 0)
>> +		return ret;
>> +	bit_center = count_bits(full_cache_mask) / 2;
>> +	cont_mask = full_cache_mask >> bit_center;
>> +
>> +	/* Contiguous mask write check. */
>> +	snprintf(schemata, sizeof(schemata), "%lx", cont_mask);
>> +	ret = write_schemata("", schemata, uparams->cpu, test->resource);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/*
>> +	 * Non-contiguous mask write check. CBM has a 0xf hole approximately in the middle.
>> +	 * Output is compared with support information to catch any edge case errors.
>> +	 */
>> +	noncont_mask = ~(full_cache_mask & (0xf << bit_center)) & full_cache_mask;
>
>Why is the full_cache_mask & part needed here? It's not like the second 
>and can grow bits outside of full_cache_mask even if that would overflow 
>the full_cache_mask (it won't be testing hole then though but that 
>problem happens also at the boundary condition one bit prior to 
>overflowing the mask).

Okay, I see what you mean. Thanks, I'll remove the first operation. While
testing it also occurred to me that the the 0xf wide hole is offset by two bits
to the left so I'll adjust that in the next version.

>> +	snprintf(schemata, sizeof(schemata), "%lx", noncont_mask);
>> +	ret = write_schemata("", schemata, uparams->cpu, test->resource);
>> +	if (ret && sparse_masks)
>> +		ksft_print_msg("Non-contiguous CBMs supported but write failed\n");
>> +	else if (ret && !sparse_masks)
>> +		ksft_print_msg("Non-contiguous CBMs not supported and write failed as expected\n");
>> +	else if (!ret && !sparse_masks)
>> +		ksft_print_msg("Non-contiguous CBMs not supported but write succeeded\n");
>
>Newline.

Sure, will add.

>> +	return !ret == !sparse_masks;
>> +}
>> +
>> +static bool noncont_cat_feature_check(const struct resctrl_test *test)
>> +{
>> +	char res_path[PATH_MAX];
>> +	struct stat statbuf;
>> +
>> +	snprintf(res_path, sizeof(res_path), "%s/%s/%s", INFO_PATH,
>> +		 test->resource, "sparse_masks");
>> +
>> +	if (stat(res_path, &statbuf))
>> +		return false;
>
>This looks generic enough that validate_resctrl_feature_request() should 
>be somehow adapted to cover also these cases. Perhaps it would be best to 
>just split validate_resctrl_feature_request() into multiple functions.

As in conditionally call a function inside validate_resctrl_feature_request()
that would check for the existance of a particular file that would indicate if a
feature is supported or not?

Does implementing it as a new entry in resctrl_test struct that would hold the
desired filename seem reasonable? Or would it be better to pass it as a new
function argument (similiar to how "const char *feature" is used now)?

>> +	return test_resource_feature_check(test);
>> +}
>> +
>>  struct resctrl_test l3_cat_test = {
>>  	.name = "L3_CAT",
>>  	.group = "CAT",
>> @@ -357,3 +438,19 @@ struct resctrl_test l2_cat_test = {
>>  	.feature_check = test_resource_feature_check,
>>  	.run_test = cat_run_test,
>>  };
>> +
>> +struct resctrl_test l3_noncont_cat_test = {
>> +	.name = "L3_NONCONT_CAT",
>> +	.group = "NONCONT_CAT",
>
>> +struct resctrl_test l2_noncont_cat_test = {
>> +	.name = "L2_NONCONT_CAT",
>> +	.group = "NONCONT_CAT",
>
>I think these should be grouped among "CAT" group because it well, tests 
>CAT functionality. Why you think a separate group for them is needed?

It was convenient for my test purposes and I guess I didn't rethink that part
later. So you're right, it fits better grouped with CAT, I'll change it.

-- 
Kind regards
Maciej Wiecz?r-Retman