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;
Message-ID: <4062bb5c-1e9c-5e1f-5b27-2a4a8fb58078@intel.com>
Date:   Thu, 10 Mar 2022 13:42:01 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online
 cpus for scan test
Content-Language: en-US
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>
References: <20220301195457.21152-1-jithu.joseph@intel.com>
 <20220301195457.21152-8-jithu.joseph@intel.com>
 <09b5b05018a8600ca8fab896790ab16827c80e4e.camel@intel.com>
 <e282377b-8ee4-99fc-432f-2aa3441b2989@intel.com>
 <CAPcyv4gcfMZu38EAGBq59A-RPUmR3fFiamRiR6QaP=D1gPS+6A@mail.gmail.com>
 <1503c7940a7149679025173a46dd0daf@intel.com>
From:   "Kok, Auke" <auke-jan.h.kok@intel.com>
In-Reply-To: <1503c7940a7149679025173a46dd0daf@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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