Re: [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online cpus for scan test

[Kok, Auke]

On 3/7/22 09:46, Luck, Tony wrote:
> > > These are software(driver) defined error codes. Rest of the error codes are supplied by
> > > the hardware. Software defined error codes were kept at the other end to provide ample space
> > > in case (future) hardware decides to provide extend error codes.
> > Why put them in the same number space? Separate software results from
> > the raw hardware results and have a separate mechanism to convey each.
> We wanted to include in the "details" file, which is otherwise a direct copy of
> the SCAN_STATUS MSR. Making sure the software error codes didn't overlap
> with any h/w generated codes seemed like a good idea.
>
> But maybe we should have done this with additional string values in the status
> file:
>
> Current:
>
> pass
> untested
> fail
>
> Add a couple of new options for the s/w cases:
>
> sw_timeout
> sw_retries_exceeded


We've made a userspace implementation for this API already as part of 
opendcdiag that uses it:

https://github.com/opendcdiag/opendcdiag/commit/0cbfcee30e0666b0f79a2e452d7f8167d2a0cb90

What I really like is that with this proposed API, we can unambiguously 
determine whether "the core failed" or "everything is fine, for now" by 
reading a single file. I hate to see this file become unusable because 
its content changes from "pass" to "sw_timeout" or, even worse, it 
changes from "fail" to "sw_timeout". That would render it useless for 
the purpose that I think our users will be looking at it.

So, my preference would be to keep this file functioning as-is in this 
patch series.

I would think that some sort of expandable "statistics" file would be a 
better way to output various metrics:

```

sw_timeout: 0

sw_retries_exceeded: 2

runs: 42

first_run: 1405529347

last_run: 1646948140

<etc..>

```

just as a suggested alternative for more/incompatble output values or a 
complex, dynamic format.

I don't have any use in opendcdiag for these values and data. If someone 
does, they should want to chime in perhaps.


Auke