From: Ashok Raj <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML Mailing List <linux-kernel@vger.kernel.org>,
X86-kernel <x86@kernel.org>, Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@amacapital.net>,
Ingo Molnar <mingo@kernel.org>,
Tom Lendacky <thomas.lendacky@amd.com>,
Tony Luck <tony.luck@intel.com>, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH] x86/microcode/intel: Allow late loading only if a min rev is specified
Date: Mon, 29 Aug 2022 22:41:56 +0000 [thread overview]
Message-ID: <Yw1AtFrRPWhkJ4r8@araj-dh-work> (raw)
In-Reply-To: <Yw0iDnZ+dB4ULSs/@nazgul.tnic>
On Mon, Aug 29, 2022 at 10:31:22PM +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2022 at 06:04:36PM +0000, Ashok Raj wrote:
> > @@ -886,7 +905,7 @@ static bool is_blacklisted(unsigned int cpu)
> > }
> >
> > static enum ucode_state request_microcode_fw(int cpu, struct device *device,
> > - bool refresh_fw)
> > + bool late_loading)
> > {
>
> Until the refresh_fw's function hasn't been clarified:
>
> https://lore.kernel.org/all/YwaBim3Xt3Il3KXm@zn.tnic/
>
I don't know exactly what you mean.
But I suppose, you mean what refresh_hw is supposed to mean from the existing code?
refresh_hw seems to imply when to update the copy of the microcode from
the filesystem. Also seems to imply late loading.
its used in the following places.
1. During reload_store() where this is exclicitly due to echo 1 > reload
tmp_ret = microcode_ops->request_microcode_fw(bsp, µcode_pdev->dev, true);
Here passing true makes sense since you are going to do a full
refresh on all CPUs via late loading.
2. microcode_update_cpu() -> microcode_init_cpu()->request_microcode_fw(false)
Early loading from resume. So we would use the microcode cache to load
from.
3. mc_device_add() -> microcode_init_cpu(true)->request_microcode_fw(true)
This seems like normal CPU hot-add, I'm not sure if refresh_fw=true is
valid. A new CPU should also use from the cache, but not a full reload
from filesystem. This could end up with new cpu with an updated ucode
and older with something that was loaded earlier. Sort of what was fixed
in:
commit 7189b3c11903667808029ec9766a6e96de5012a5 (tag: x86_microcode_for_v5.13)
intel.c doesn't seem to use this parameter at all today. But judging from
amd.c: request_microcode_amd()
/* reload ucode container only on the boot cpu */
if (!refresh_fw || !bsp)
return UCODE_OK;
Seems like it does the right job, since you would refresh only if
refresh_fw=true and its the bsp. Hence it seems immute to the
mc_device_add() bug.
1. Fix mc_device_add() to set refresh_fw() to false.
2. We can change the parameter to late_loading as you had alluded in
previous post.
3. Use that to distinguish if we need to enforce the
microcode_sanity_check() to validate min_rev.
Let me know if this is what you meant.
Cheers,
Ashok
next prev parent reply other threads:[~2022-08-29 22:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 18:04 [PATCH] x86/microcode/intel: Allow late loading only if a min rev is specified Ashok Raj
2022-08-29 18:36 ` Dave Hansen
2022-08-29 18:52 ` Ashok Raj
2022-08-29 20:24 ` Dave Hansen
2022-08-29 20:31 ` Borislav Petkov
2022-08-29 22:41 ` Ashok Raj [this message]
2022-09-01 2:53 ` Borislav Petkov
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=Yw1AtFrRPWhkJ4r8@araj-dh-work \
--to=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--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