linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ashok Raj <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Tony Luck <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	LKML Mailing List <linux-kernel@vger.kernel.org>,
	X86-kernel <x86@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Jacon Jun Pan <jacob.jun.pan@intel.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v3 2/5] x86/microcode/intel: Allow a late-load only if a min rev is specified
Date: Thu, 25 Aug 2022 04:02:07 +0000	[thread overview]
Message-ID: <Ywb0PwxU7KMMetyu@araj-dh-work> (raw)
In-Reply-To: <YwaBim3Xt3Il3KXm@zn.tnic>

On Wed, Aug 24, 2022 at 09:52:42PM +0200, Borislav Petkov wrote:
> On Tue, Aug 23, 2022 at 12:08:27AM +0000, Ashok Raj wrote:
> > Correct, but print_err parameter is 0 when called from scan_microcode() and 1
> > when called from generic_load_microcode().
> 
> Well, scan_microcode() gets called from save_microcode_in_initrd() which
> is fs_initcall and if we had to be really precise, print_err being 0
> there is wrong.
> 
> Because at fs_initcall time we can very well print error messages. But
> that print_err thing is an old relic so will have to get fixed some
> other day.

Well, the code hasn't changed since 2016, and possibly they migrated from
another file. 
> 
> > We do min_rev enforcement only when print_err is set.
> 
> That's wrong - you need to do min_rev enforcement only when you're
> loading microcode late. I.e., to paste from my previous mail:

True, if this hasn't been used for soo long, I was hoping to simply rename
the variable as late_load, and repurpose it.. 

As you mention we do have some good opportunity to perform some cleanups
here, and could address at that time.

If you feel compelled to turn the print on early boot, I could flip it and
send it along with my other changes? Let me know if you prefer that.


And I'll pursue what you said below. I still like the
microcode_sanity_check(), it sort of falls in that category. I can add
another parameter passing all the way from the request_fw... come through
all the other interceptors and land in the same spot.

The microcode_sanity_check() was nicely isolated Intel only function and
didn't need to perform surgery where it wasn't necessary :-).. 

Good bang for the buck :-)
> 
> "So you'd have to pass down the fact that you're doing late loading from
> request_microcode_fw().
> 
> Now, I'm staring at that ugly refresh_fw bool arg in that function and
> I *think* I did it 10 years ago because it shouldn't try to load from
> the fs when it is resuming because there might not be a fs yet... or
> something to that effect.
> 
> tglx might have a better idea how to check we're in the ->starting
> notifier..."
> 
> IOW, we're going to have to do something like
> 
> ->request_microcode_fw(, ... late_loading=true)

Sure, I'll check with how Thomas prefers it. 
> 
> and I wanted to reuse that refresh_fw arg instead of adding another
> one...
> 
> HTH.

YTH!

Cheers,
Ashok

  reply	other threads:[~2022-08-25  4:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17  5:11 [PATCH v3 0/5] Making microcode late-load robust Ashok Raj
2022-08-17  5:11 ` [PATCH v3 1/5] x86/microcode/intel: Check against CPU signature before saving microcode Ashok Raj
2022-08-17  7:43   ` Ingo Molnar
2022-08-17 10:45     ` Ashok Raj
2022-08-19 10:24   ` Borislav Petkov
2022-08-23 11:13     ` Ashok Raj
2022-08-24 19:27       ` Borislav Petkov
2022-08-25  3:27         ` Ashok Raj
2022-08-26 16:24           ` Borislav Petkov
2022-08-26 17:18             ` Ashok Raj
2022-08-26 17:29               ` Borislav Petkov
2022-08-17  5:11 ` [PATCH v3 2/5] x86/microcode/intel: Allow a late-load only if a min rev is specified Ashok Raj
2022-08-17  7:45   ` Ingo Molnar
2022-08-19 11:11   ` Borislav Petkov
2022-08-23  0:08     ` Ashok Raj
2022-08-24 19:52       ` Borislav Petkov
2022-08-25  4:02         ` Ashok Raj [this message]
2022-08-26 12:09           ` Borislav Petkov
2022-08-17  5:11 ` [PATCH v3 3/5] x86/microcode: Avoid any chance of MCE's during microcode update Ashok Raj
2022-08-17  7:41   ` Ingo Molnar
2022-08-17  7:58     ` Ingo Molnar
2022-08-17  8:09       ` Borislav Petkov
2022-08-17 11:57         ` Ashok Raj
2022-08-17 12:10           ` Borislav Petkov
2022-08-17 12:30             ` Ashok Raj
2022-08-17 14:19               ` Borislav Petkov
2022-08-17 15:06                 ` Ashok Raj
2022-08-29 14:23                   ` Andy Lutomirski
2022-08-17 11:40     ` Ashok Raj
2022-08-17  5:11 ` [PATCH v3 4/5] x86/x2apic: Support x2apic self IPI with NMI_VECTOR Ashok Raj
2022-08-17  5:11 ` [PATCH v3 5/5] x86/microcode: Place siblings in NMI loop while update in progress Ashok Raj
2022-08-30 19:15   ` Andy Lutomirski

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=Ywb0PwxU7KMMetyu@araj-dh-work \
    --to=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --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).