Re: [RFC 00/10] Introduce In Field Scan driver

["Williams, Dan J" <dan.j.williams@intel.com>]

On Tue, 2022-03-01 at 11:54 -0800, Jithu Joseph wrote:
> Note to Maintainers:
> Requesting x86 Maintainers to take a look at patch01 as it
> touches arch/x86 portion of the kernel. Also would like to guide them
> to patch07 which sets up hotplug notifiers and creates kthreads.
> 
> Patch 2/10 - Adds Documentation. Requesting Documentation maintainer to review it.
> 
> Requesting Greg KH to review the sysfs changes added by patch08.
> 
> Patch10 adds tracing support, requesting Steven Rostedt to review that.
> 
> Rest of the patches adds the IFS platform driver, requesting Platform driver maintainers
> to review them.
> 
> 
> In Field Scan (IFS) is a hardware feature to run circuit level tests on
> a CPU core to detect problems that are not caught by parity or ECC checks.
> 
> Intel will provide a firmware file containing the scan tests.  Similar to
> microcode there is a separate file for each family-model-stepping. The
> tests in the file are divided into some number of "chunks" that can be
> run individually.
> 
> The driver loads the tests into memory reserved BIOS local to each CPU
> socket in a two step process using writes to MSRs to first load the
> SHA hashes for the test. Then the tests themselves. Status MSRs provide
> feedback on the success/failure of these steps.
> 
> Tests are run by synchronizing execution of all threads on a core and
> then writing to the ACTIVATE_SCAN MSR on all threads. Instruction
> execution continues when:
> 
> 1) all tests have completed
> 2) execution was interrupted
> 3) a test detected a problem
> 
> In all cases reading the SCAN_STATUS MSR provides details on what
> happened. Interrupted tests may be restarted.

Can you say a bit about what motivates upstream to want to carry this
support? For example, if the test content comes from out of tree (i.e.
there is no source for tests other then a location under a URL on
github.com/intel), and nothing in the kernel consumes the results, then
what breaks if that blob from the test URL also has a a few source
files and a Kbuild file to produce a .ko alongside the .scan file? This
is more a comment on the cover letter basics than an actual proposal to
change the distribution model. Just, in general, the cover letter
clarifies why upstream should care about the patches.