Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 13 Nov 2022 07:15:03 -0800
From:   Ashok Raj <ashok.raj@intel.com>
To:     Borislav Petkov <bp@alien8.de>
CC:     "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        Thiago Macieira <thiago.macieira@intel.com>,
        "Luck, Tony" <tony.luck@intel.com>,
        "Joseph, Jithu" <jithu.joseph@intel.com>,
        "hdegoede@redhat.com" <hdegoede@redhat.com>,
        "markgross@kernel.org" <markgross@kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Jimenez Gonzalez, Athenas" <athenas.jimenez.gonzalez@intel.com>,
        "Mehta, Sohil" <sohil.mehta@intel.com>,
        Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs
 entry
Message-ID: <Y3EJ93xzgC/1v0WV@a4bf019067fa.jf.intel.com>
References: <20221021203413.1220137-1-jithu.joseph@intel.com>
 <20221107225323.2733518-1-jithu.joseph@intel.com>
 <20221107225323.2733518-13-jithu.joseph@intel.com>
 <Y2/JNAmSoYlLKq3A@zn.tnic>
 <CC3629D6-B205-4150-80E5-FC7A7A76DD25@intel.com>
 <Y3CevK2zhAmiUyG9@kroah.com>
 <Y3DZmKYV+8HBtZ+Q@zn.tnic>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y3DZmKYV+8HBtZ+Q@zn.tnic>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?BXhwtjXA1nNuuEOL9GdXedVsFVGfiTTMykI5h2pYq8btdwIkFNgLwZGq03W5?=
 =?us-ascii?Q?BkPAj+Ffpzwv8J8AmFc1q6GPWtxqyM6Z9Pdw+KgdEzKnpUJTzkYF6YAXqFgk?=
 =?us-ascii?Q?wVSA/nemACFmE4q00bw8YsuVFP+RvQ+i2QuPFjtgKyjkF2rhTdyT5SbUjlyf?=
 =?us-ascii?Q?lKUNetN1C10K4P6MA/269rKxAjWoG6Xk1NFKmxHpvYY7LERGdcPF1wIjvjE8?=
 =?us-ascii?Q?Npqb2PVxW1Vr7cXeTyxl2f8D+B2LZS8xi+CYNCq7Lu+DviLHpT3uxzLUBA5E?=
 =?us-ascii?Q?7raRwawDNNcr4MPNxu0aiKB/rCBSAIq5CXYWUQCSChZvuNyIrI+BZqKbT3L5?=
 =?us-ascii?Q?Cv2+gVPQDQ1G9PRxxWcNf/uoJBSa9Lr0R0t26X1L6B8ujOUYitlitdXbMqO0?=
 =?us-ascii?Q?dwFDsIdPlMctDcKWlUCVzEi6RmEXucfM//IiumOUMuR5XK9FHg7p7pCbWNlQ?=
 =?us-ascii?Q?wHoX9e+4Deb0/1GBqtIMJN59HGN//VONbNbL4SHDIjPIH5hWsLNJ+0cCO8QH?=
 =?us-ascii?Q?Zn/0kfwwa/psxBSUASgUcO7Q8aIfrylOXnNYygrnziyiU7fk7A1MWib7s/ul?=
 =?us-ascii?Q?eiPZHsKYb8ucbYUldBOuBqd/+CH1RHcN0kN7Glgf3oYYdYayzjjewY18bkmN?=
 =?us-ascii?Q?4bac6yz7xbtoa1f8Dao7liO5AyDNyoOrYYeFUQ7zN/Pu4Mt2lyt/7BI603of?=
 =?us-ascii?Q?9Hq+b9xOQucO5QcNGwmOZbS+uO04WWvmRTkciPPCZsq3rHauD6d4IxyX5eGc?=
 =?us-ascii?Q?x/WX8pSJ6GTBe3+f6aZZvXBLvL5AUrrjTSDhvzKjBq5ODI61Msjwuzon9A90?=
 =?us-ascii?Q?0pSbTs+woHj5YugzOSbf20ItyWWshczCgG2Vpu8SwyzAoHToy6g5fcN3iVlL?=
 =?us-ascii?Q?NcaHF5d0EnbPWU7gDfiXx/cKnwsFdrkMX16BuCcjskN/TUU5NrC/iSpkQPOE?=
 =?us-ascii?Q?GOZB6FL3qNf4sjDTPk1wANXPw8wcRMfkWc8mw+Bvg3p3pdwL2Jk/x5iv5Xyb?=
 =?us-ascii?Q?7l6C3Xq468XCRP3Um0vWgza6biGW0tEVnVatd0mVj4nQV55l1pt5A3JXg5pB?=
 =?us-ascii?Q?WDnKzn243x9iK01sydMeslaVbP61dG5ji4bB9BFhxTkdpaI/nQQANzMeI11t?=
 =?us-ascii?Q?Z/3dM/6X+PTzXaUaGID8sXnaj47a3Kc5TlZkJ/AKEPZNBXkFkrwRG3LqBqfn?=
 =?us-ascii?Q?BDezntTFuBXfAN8PJf8vVbfhusYvMzQkXrQXo/SJOAf6wzVqzR61hBBSK9g1?=
 =?us-ascii?Q?IhHW/HPjhffBnb3KnSRgxD4ol3KpcZYBFG8S/1taCQq0T7jpyqyMlVIaYAuy?=
 =?us-ascii?Q?b0/NP9fX0MNP5HKRA9kaQ1KBvEjvsOR+tG8OA1uF3arZrWjaCT0M2K2hRjZw?=
 =?us-ascii?Q?nU1Uwp9JxJdQOljEdKWufKOYdr5nZ1RmdGMXY+UYC81exKVCb6GuR4cMexqX?=
 =?us-ascii?Q?c4AjeCbDfxjBGdq5YQCFclucWI10s/XGzO7krcDYOO4wJL7Msd/TXooMFO18?=
 =?us-ascii?Q?pae5LYp4c+5ThD8OAJJj/FDxCv5e0thHQzr45LO5+QTxKgmuBfxBvqugq3Rx?=
 =?us-ascii?Q?sV4zZ4A1tqINwQotBWBpsos/NZY0MaYj7JSGsCQI?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c375e1ba-2908-4bd3-facb-08dac589da17
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2022 15:15:08.8572
 (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: Yi/0fo8XH6TvY8OVZhtqV2wSrU/7diU+U9/KbLaj5Hotb9Gix0aZpxfw4Niudk0/I8H2arANgGdXgQesFrOeDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7371
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Nov 13, 2022 at 12:48:40PM +0100, Borislav Petkov wrote:
> Replying to both with one mail because it still feels like there's a
> misunderstanding.
> 
> On Sun, Nov 13, 2022 at 08:37:32AM +0100, gregkh@linuxfoundation.org wrote:
> > No, please do not force the driver to resolve a filename path in the
> > kernel.
> 
> No, I don't mean to do any filename path resolving - all I suggest is to
> echo into sysfs the full filename instead of the number. I.e., this:
> 
> for i in $(ls /lib/firmware/intel/ifs_0/*.scan);
> do
> 	echo $i /sys/devices/virtual/misc/intel_ifs_0/current_batch
> done
> 
> What you end up echoing inside is only the full filename - *not* the
> absolute filename - instead of a number. So those in a succession:
> 
> 06-8f-06-00.scan
> 06-8f-06-01.scan
> 06-8f-06-02.scan
> 06-8f-06-03.scan
> 06-8f-06-04.scan
> 06-8f-06-05.scan

Do you expect the /lib/firmware/intel/ifs_0/ to contain *ONLY* files for
this platform? For microcode we have everything in the public release
included here. 

In the above proposal, you can *ONLY* put files for this platform unlike simply
copying everything released and let the kernel pick the right one since it
does the ff-mm-ss-*.scan lookup. Only the batch number is supplied from
user space.

> 
> The advantage being, you don't need to remember which file sequence and
> which family/model/stepping.

Even in the current implementation, user doesn't need to know f/m/s. That's
something the driver selects automatically, just like what microcode does
for reload.

> 
> For all Intel employees here on the thread, there's a world outside
> Intel and people do not talk (family model stepping) tuples like we do.
> All they wanna do is run their damn tests.
> 
> So instead of what the code does now:
> 
> +	snprintf(scan_path, sizeof(scan_path), "intel/ifs_%d/%02x-%02x-%02x-%02x.scan",
> +		 ifsd->test_num, boot_cpu_data.x86, boot_cpu_data.x86_model,
> +		 boot_cpu_data.x86_stepping, ifsd->cur_batch);
> 
> It would still use the *same* scan_path - /lib/firmware/intel/ifs_0/ -
> no one is proposing to give a full path name - it would only use the
> filename string - 06-8f-06-00.scan, for example - instead of the "0" in
> it to build that string.
> 
> And, ofcourse it would check the format of that string against family,
> model, stepping and sequence number (btw this way you drop your
> limitation of 256 for the sequence number which you don't really need
> either).
> 
> And then if the format passes, it would check the headers.
> 
> And only if those pass too, then it would load.

Isn't it simple now? No need to check if user supplied the right f/m/s
since its not a user input, kernel composes that automatically.

> > Right, it's no different from echoing file names, but it's much
> > simpler to increment a number than do a directory listing and sort the
> > file names, so it can pick up from where it left off.
> 
> It is no different - you still need to remember where you are in the
> sequence wrt to testing.
> 
> So if you want to deal with the timeout, that same script above will
> check the status and wait. Not rocket science.
> 
> As to this Thiago:
> 
> > You can't do it with a three-line shell script, but we're not
> > expecting that shell scripts are the means to use this feature in the
> > first place.
> 
> I consider it a serious design mistake of having to have a *special*
> tool. A special tool is *always* a burden. You need to build it, supply
> it, make sure it is installable on the target system and so on.
> 
> And I'm telling you this with my Linux distributor hat on. It is always
> a pain - trust me.
> 
> For example, there's a reason why you can still control ftrace from the
> command line and you don't need any tool. You *can* use a tool but you
> don't have to. IOW, the KISS philosophy.

The tool we have is not for a simple test run. That can easily be done with
a shell script. The tool does a bit more like handling retries if the test
was not scheduled. The fundamental pass/fail simply output is what the
kernel provides. 

> 
> IOW, I really think that designing our interfaces with user friendliness
> in mind should be of much more higher importance. And requiring the user
> to remember or figure out anything she doesn't really need to, in order
> to run the test is a burden.
> 
> Just look at microcode loading: early loading works automatically - you
> only need to install the blobs in /lib/firmware/intel-ucode/. The initrd
> builder figures out which to add to the image.
> 
> And not even that is required - I have a script which adds *all* blobs
> to my image. It still loads the right one.
> 
> Late loading works also trivially:
> 
> echo 1 > /sys/devices/system/cpu/microcode/reload
> 
> And it goes and builds the filename from f/m/s and loads it from the
> hardcoded path - no filename resolving.
> 
> But it doesn't ask the user to give a f/m/s or a sequence number.

I don't think the current proposed interface expects a f/m/s. The entire
IFS design was sort of mimicking the microcode interface. 

The V1 submission did pretty much that. But it required copying files from
some place to /lib/firmware so they can echo 1 > reload.

Instead of copying files over that *did* sound like a hack, the batch was
introduced and that's the only thing needed from user input. 

The utility is more like icing, to run a simple test all you need is a
simple script. It is not a baseline requirement.

Cheers,
Ashok