Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   "Luck, Tony" <tony.luck@intel.com>
To:     Andy Lutomirski <luto@kernel.org>
CC:     "Joseph, Jithu" <jithu.joseph@intel.com>,
        "hdegoede@redhat.com" <hdegoede@redhat.com>,
        "markgross@kernel.org" <markgross@kernel.org>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "Borislav Petkov" <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Jonathan Corbet <corbet@lwn.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@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>
Subject: RE: [RFC 00/10] Introduce In Field Scan driver
Thread-Topic: [RFC 00/10] Introduce In Field Scan driver
Thread-Index: AQHYLaZcmKq0UuRYGU6xp1k7P7vRw6yspmuA///mywCAAJPCgP//faKA
Date:   Wed, 2 Mar 2022 21:41:55 +0000
Message-ID: <f927a309de734c50a5ea8e62077e9e30@intel.com>
References: <20220301195457.21152-1-jithu.joseph@intel.com>
 <1b793ead-a47c-4719-b7b5-cba7d49633f2@www.fastmail.com>
 <Yh/Tt50Y8ubGNwS6@agluck-desk3.sc.intel.com>
 <bdc14f77-98e0-4af8-9bef-5dd3d41f22c2@www.fastmail.com>
In-Reply-To: <bdc14f77-98e0-4af8-9bef-5dd3d41f22c2@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.401.20
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

> How does this work?  Is there an Intel IFS blob v1.17 that is expected
> to be *the* blob for a given CPU until an update happens?

This is the model. Although internally the blob is divided into chunks
that can be run separately, folks outside Intel have no visibility into
which chunk tests which circuits (even *inside* ... I don't know what
each chunk does :-) )

How often will updates occur? No idea. Since this is new, I'd expect
that there might be some improvements when there is feedback from
large CSPs running on many more systems than we have.

>  Or is the
> expectation that several different blobs might all useful on the same
> system and operators might want to run different blobs under different
> circumstances?

One of our early implementations included extra sysfs hooks to only
test specific chunks ... but we dropped that complexity as there's no
way for end users to decide which chunks to run.

So the posted series just iterates all chunks for a core.

-Tony