[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180105133217.GB12036@kroah.com>
Date: Fri, 5 Jan 2018 14:32:17 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Andrea Arcangeli <aarcange@...hat.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dave Hansen <dave.hansen@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Arjan Van De Ven <arjan.van.de.ven@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode
reload
On Thu, Jan 04, 2018 at 07:50:33PM +0100, Borislav Petkov wrote:
> On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote:
> > void spec_ctrl_rescan_cpuid(void)
> > {
> > int cpu;
> >
> > if (use_ibp_disable)
> > return;
> > mutex_lock(&spec_ctrl_mutex);
> > if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> > boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> > /* detect spec ctrl related cpuid additions */
> > init_scattered_cpuid_features(&boot_cpu_data);
>
> You don't need to noodle through all the scattered features - just the
> two bits.
Does it really matter? Rescanning everything can't hurt here, and it
shouldn't be noticable in any boot time chart. I feel like arguing
about tiny stuff like this takes away from the obvious other problems
this whole patch series had :(
But hey, I'm guilty of it numerous times as well, I know, so I'll shut
up now...
thanks,
greg k-h
Powered by blists - more mailing lists