Message ID | 20220428153849.295779-1-tony.luck@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce In Field Scan driver | expand |
On Thu, Apr 28, 2022 at 08:38:39AM -0700, Tony Luck wrote: > Hopefully this is close enough to done to begin discussion on which > maintainer tree will take this series. > > Choices: > 1) Hans/Mark take it into the platform-drivers tree > Needs an Ack from x86 maintainers on parts 1 & 2 > 2) X86 maintainers take it into TIP > Needs Ack from Hans/Mark on parts 2-10 > > TL;DR this driver loads scan test files that can check whether silicon > in a CPU core is still running correctly. It is expected that these tests > would be run several times per day to catch problems as silicon ages. Much nicer and simpler as compared to the first version submitted, thanks for sticking with it. The diff seems about 1/3 smaller from the first version sent out, peer-review works :) Reviewed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Much nicer and simpler as compared to the first version submitted, > thanks for sticking with it. The diff seems about 1/3 smaller from the > first version sent out, peer-review works :) > > Reviewed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks for your patience leading me to a much better driver. -Tony
Hi, On 4/28/22 17:38, Tony Luck wrote: > Hopefully this is close enough to done to begin discussion on which > maintainer tree will take this series. > > Choices: > 1) Hans/Mark take it into the platform-drivers tree > Needs an Ack from x86 maintainers on parts 1 & 2 > 2) X86 maintainers take it into TIP > Needs Ack from Hans/Mark on parts 2-10 I've taken a quick look at the entire series and it looks good to me. I'm fine with this entire series getting merged through the TIP tree, here is my ack for merging the drivers/platform/x86 bits through the TIP tree: Acked-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans > > TL;DR this driver loads scan test files that can check whether silicon > in a CPU core is still running correctly. It is expected that these tests > would be run several times per day to catch problems as silicon ages. > > Changes since v4: > > Greg Kroah-Hartman > ------------------ > "Cute way to do this, but I don't see you ever have any more devices > added to this list in this series." > > Removed the enum, arrays, loops, and count of test types discovered. > Now just check for enumeration of the single test type that is being > deployed on Sapphire Rapids. > > > Jithu Joseph (7): > x86/microcode/intel: Expose collect_cpu_info_early() for IFS > platform/x86/intel/ifs: Read IFS firmware image > platform/x86/intel/ifs: Check IFS Image sanity > platform/x86/intel/ifs: Authenticate and copy to secured memory > platform/x86/intel/ifs: Add scan test support > platform/x86/intel/ifs: Add IFS sysfs interface > platform/x86/intel/ifs: add ABI documentation for IFS > > Tony Luck (3): > x86/msr-index: Define INTEGRITY_CAPABILITIES MSR > platform/x86/intel/ifs: Add stub driver for In-Field Scan > trace: platform/x86/intel/ifs: Add trace point to track Intel IFS > operations > > .../ABI/testing/sysfs-platform-intel-ifs | 39 ++ > MAINTAINERS | 8 + > arch/x86/include/asm/cpu.h | 18 + > arch/x86/include/asm/msr-index.h | 7 + > arch/x86/kernel/cpu/intel.c | 32 ++ > arch/x86/kernel/cpu/microcode/intel.c | 59 +--- > drivers/platform/x86/intel/Kconfig | 1 + > drivers/platform/x86/intel/Makefile | 1 + > drivers/platform/x86/intel/ifs/Kconfig | 13 + > drivers/platform/x86/intel/ifs/Makefile | 3 + > drivers/platform/x86/intel/ifs/core.c | 80 +++++ > drivers/platform/x86/intel/ifs/ifs.h | 123 +++++++ > drivers/platform/x86/intel/ifs/load.c | 262 ++++++++++++++ > drivers/platform/x86/intel/ifs/runtest.c | 332 ++++++++++++++++++ > drivers/platform/x86/intel/ifs/sysfs.c | 147 ++++++++ > include/trace/events/intel_ifs.h | 38 ++ > 16 files changed, 1111 insertions(+), 52 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-ifs > create mode 100644 drivers/platform/x86/intel/ifs/Kconfig > create mode 100644 drivers/platform/x86/intel/ifs/Makefile > create mode 100644 drivers/platform/x86/intel/ifs/core.c > create mode 100644 drivers/platform/x86/intel/ifs/ifs.h > create mode 100644 drivers/platform/x86/intel/ifs/load.c > create mode 100644 drivers/platform/x86/intel/ifs/runtest.c > create mode 100644 drivers/platform/x86/intel/ifs/sysfs.c > create mode 100644 include/trace/events/intel_ifs.h > > > base-commit: af2d861d4cd2a4da5137f795ee3509e6f944a25b
> I've taken a quick look at the entire series and it looks good to me. > > I'm fine with this entire series getting merged through the TIP > tree, here is my ack for merging the drivers/platform/x86 bits > through the TIP tree: > > Acked-by: Hans de Goede <hdegoede@redhat.com> Hans, Thanks for looking, and double thanks for the "Ack". -Tony
On Mon, May 02, 2022 at 05:15:39PM +0200, Hans de Goede wrote: > I'm fine with this entire series getting merged through the TIP > tree, Hmm, so looking at the diffstat - the majority of that is drivers/platform/x86/ so I guess your tree would be better suited for it... Thx.
> Hmm, so looking at the diffstat - the majority of that is > drivers/platform/x86/ so I guess your tree would be better suited for > it... Can you check that I fixed the issues in part 01/10 that you reported in v3 of this series and give an Ack to Hans? -Tony
> Can you check that I fixed the issues in part 01/10 that you reported in v3 of this > series and give an Ack to Hans? Oops ... reading e-mail out of order ... I see that you already gave the Ack. Thanks! -Tony
Hi, On 5/3/22 17:32, Borislav Petkov wrote: > On Mon, May 02, 2022 at 05:15:39PM +0200, Hans de Goede wrote: >> I'm fine with this entire series getting merged through the TIP >> tree, > > Hmm, so looking at the diffstat - the majority of that is > drivers/platform/x86/ so I guess your tree would be better suited for > it... Ok, that also works for me and I see that the few arch/x86 already have Ack-s / Reviewed-by-s from you / tglx . I'll give it some more time for review for v6 and then pick up v6 (or v7 if review leads to more changes). Regards, Hans
> I'll give it some more time for review for v6 and then pick up v6 > (or v7 if review leads to more changes). Hans, Thomas has found one substantive problem, and a few minor things (so far ... he still seems to be working through v6). So there will be a v7. Likely early next week. Is that OK? Do you still take patches after -rc6? -Tony
Hi, On 5/6/22 17:53, Luck, Tony wrote: >> I'll give it some more time for review for v6 and then pick up v6 >> (or v7 if review leads to more changes). > > Hans, > > Thomas has found one substantive problem, and a few minor things (so far ... he > still seems to be working through v6). Ok. > So there will be a v7. Likely early next week. Is that OK? That is fine. > Do you still take patches after -rc6? If the patches are send soon (1-2 days) after rc6 I can still take them. Regards, Hans
>> Do you still take patches after -rc6? > > If the patches are send soon (1-2 days) after rc6 I can still take them. Hans, V7 was posted Friday. It survived my weekend testing, and another round of tglx scrutiny (ending with his "Reviewed-by" on the latter parts of the series. Let me know if there is anything else you need to get them applied. Thanks -Tony
Hi, On 5/9/22 19:05, Luck, Tony wrote: >>> Do you still take patches after -rc6? >> >> If the patches are send soon (1-2 days) after rc6 I can still take them. > > Hans, > > V7 was posted Friday. It survived my weekend testing, and another round of tglx scrutiny (ending with > his "Reviewed-by" on the latter parts of the series. > > Let me know if there is anything else you need to get them applied. From my side everything looks good. I plan to merge this into my review-hans (*) branch coming Wednesday. Regards, Hans *) And then from there move it to for-next once the build bots have had a chance to play with it