From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Joseph, Jithu" <jithu.joseph@intel.com>
Cc: "hdegoede@redhat.com" <hdegoede@redhat.com>,
"markgross@kernel.org" <markgross@kernel.org>,
"corbet@lwn.net" <corbet@lwn.net>,
"Raj, Ashok" <ashok.raj@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>, "bp@alien8.de" <bp@alien8.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online cpus for scan test
Date: Thu, 10 Mar 2022 13:42:01 -0800 [thread overview]
Message-ID: <4062bb5c-1e9c-5e1f-5b27-2a4a8fb58078@intel.com> (raw)
In-Reply-To: <1503c7940a7149679025173a46dd0daf@intel.com>
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
next prev parent reply other threads:[~2022-03-10 21:42 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 19:54 [RFC 00/10] Introduce In Field Scan driver Jithu Joseph
2022-03-01 19:54 ` [RFC 01/10] x86/microcode/intel: expose collect_cpu_info_early() for IFS Jithu Joseph
2022-03-01 20:08 ` Greg KH
2022-03-02 0:56 ` Joseph, Jithu
2022-03-02 10:30 ` Borislav Petkov
2022-03-03 1:34 ` Joseph, Jithu
2022-03-01 19:54 ` [RFC 02/10] Documentation: In-Field Scan Jithu Joseph
2022-03-01 20:07 ` Greg KH
2022-03-02 0:58 ` Joseph, Jithu
2022-03-01 19:54 ` [RFC 03/10] platform/x86/intel/ifs: Add driver for " Jithu Joseph
2022-03-02 23:24 ` Williams, Dan J
2022-03-02 23:31 ` Raj, Ashok
2022-03-03 0:02 ` Luck, Tony
2022-03-03 2:04 ` Joseph, Jithu
2022-03-01 19:54 ` [RFC 04/10] platform/x86/intel/ifs: Load IFS Image Jithu Joseph
2022-03-03 2:58 ` Williams, Dan J
2022-03-01 19:54 ` [RFC 05/10] platform/x86/intel/ifs: Check IFS Image sanity Jithu Joseph
2022-03-01 19:54 ` [RFC 06/10] platform/x86/intel/ifs: Authenticate and copy to secured memory Jithu Joseph
2022-03-01 19:54 ` [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online cpus for scan test Jithu Joseph
2022-03-03 4:17 ` Williams, Dan J
2022-03-03 19:59 ` Luck, Tony
2022-03-04 19:20 ` Joseph, Jithu
2022-03-07 16:52 ` Dan Williams
2022-03-07 17:46 ` Luck, Tony
2022-03-10 21:42 ` Kok, Auke [this message]
2022-03-01 19:54 ` [RFC 08/10] platform/x86/intel/ifs: Add IFS sysfs interface Jithu Joseph
2022-03-04 0:31 ` Williams, Dan J
2022-03-04 16:51 ` Luck, Tony
2022-03-04 20:42 ` Joseph, Jithu
2022-03-04 21:01 ` Luck, Tony
2022-03-21 21:15 ` Luck, Tony
2022-03-07 17:38 ` Dan Williams
2022-03-07 19:09 ` Joseph, Jithu
2022-03-07 19:15 ` Dan Williams
2022-03-07 19:55 ` Joseph, Jithu
2022-03-07 20:25 ` Dan Williams
2022-03-07 20:56 ` Joseph, Jithu
2022-03-07 21:28 ` Dan Williams
2022-03-07 21:30 ` gregkh
2022-03-07 21:33 ` Luck, Tony
2022-03-01 19:54 ` [RFC 09/10] platform/x86/intel/ifs: add ABI documentation for IFS Jithu Joseph
2022-03-04 0:57 ` Williams, Dan J
2022-03-01 19:54 ` [RFC 10/10] trace: platform/x86/intel/ifs: Add trace point to track Intel IFS operations Jithu Joseph
2022-03-01 20:17 ` Steven Rostedt
2022-03-02 1:02 ` Joseph, Jithu
2022-03-01 20:10 ` [RFC 00/10] Introduce In Field Scan driver Greg KH
2022-03-01 20:14 ` Greg KH
2022-03-14 23:10 ` Luck, Tony
2022-03-15 7:34 ` Greg KH
2022-03-15 14:59 ` Luck, Tony
2022-03-15 15:26 ` Greg KH
2022-03-15 16:04 ` Dan Williams
2022-03-15 16:09 ` Dan Williams
2022-03-15 16:10 ` Luck, Tony
2022-03-16 8:09 ` Greg KH
2022-03-02 15:33 ` Steven Rostedt
2022-03-02 16:20 ` Greg KH
2022-03-02 13:59 ` Andy Lutomirski
2022-03-02 20:29 ` Luck, Tony
2022-03-02 21:18 ` Andy Lutomirski
2022-03-02 21:41 ` Luck, Tony
2022-03-02 23:11 ` Williams, Dan J
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4062bb5c-1e9c-5e1f-5b27-2a4a8fb58078@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=jithu.joseph@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mingo@redhat.com \
--cc=patches@lists.linux.dev \
--cc=platform-driver-x86@vger.kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).