From: Borislav Petkov <bp@alien8.de>
To: Torsten Kaiser <just.for.lkml@googlemail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Jacob Shin <jacob.shin@amd.com>,
Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]Fix early microcode loading on AMD
Date: Wed, 24 Jul 2013 16:19:27 +0200 [thread overview]
Message-ID: <20130724141927.GI30777@pd.tnic> (raw)
In-Reply-To: <CAPVoSvR30mjRq8Kcp34akb6R1oTi4Y+z7CCO_8FWK5cGd-W61A@mail.gmail.com>
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> > The other problem I see is not updating c->microcode since it is going
> > to be overwritten by smp_store_cpu_info, which is unfortunate.
> >
> > And I don't see where Intel are updating that cpuinfo_x86.microcode
> > field on early load too.
> >
> > So, AFAICT, c->microcode would remain unset when we only do early
> > microcode load. But that is something we should fix as a later patch.
>
> I don't see a problem with that staying unset.
> apply_microcode_amd() directly reads the rev from
> MSR_AMD64_PATCH_LEVEL so it does not depend on that being correct.
> And smp_store_(boot)_cpu_info will also read the current rev directly
> from the CPU to fill ->microcode.
We need to store the actual microcode revision to c->microcode for
/proc/cpuinfo and MCE.
>
> > So I think you should switch load_ucode_amd_ap to __apply_microcode_amd:
> >
> > p = find_patch()
> >
> > __apply_microcode_amd(p->mc_data);
> >
> > which should take care of the issue you're seeing, IMHO.
>
> The issue I'm seeing is that collect_cpu_info_amd_early() fills c->x86
> but not c->x86_vendor.
> Which breaks cpu_has_amd_erratum() and then Erratum 400 breaks the boot.
>
> I did not really want to switch from apply_microcode_amd() to
> __apply_microcode_amd() because then I would lose the check if the new
> microcode is really an upgrade.
Well, if the BSP has already loaded the pcache, there's no need for
the AP to parse and load the same microcode blobs file for the initrd,
right?
> >> * load_ucode_ap(): Quick exit for !cpu, because without load_microcode_amd()
> >> getting called apply_microcode_amd() can't do anything. Exit, if no microcode
> >> could be loaded.
> >
> > This could probably be a WARN_ON(!cpu) to catch errors...
>
> No, load_ucode_ap() will be called for cpu == 0.
This needs fixing IMO...
Btw, thanks for looking at this and asking critical questions!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-07-24 14:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 11:58 [PATCH]Fix early microcode loading on AMD Torsten Kaiser
2013-07-23 12:02 ` H. Peter Anvin
2013-07-23 12:23 ` Borislav Petkov
2013-07-23 15:15 ` Borislav Petkov
2013-07-23 16:57 ` Torsten Kaiser
2013-07-24 13:41 ` Borislav Petkov
2013-07-24 14:20 ` Torsten Kaiser
2013-07-24 17:49 ` Borislav Petkov
2013-07-24 13:56 ` Borislav Petkov
2013-07-24 14:44 ` Torsten Kaiser
2013-07-24 18:06 ` Borislav Petkov
2013-07-24 14:14 ` Borislav Petkov
2013-07-24 14:19 ` Borislav Petkov [this message]
2013-07-24 15:01 ` Torsten Kaiser
2013-07-24 18:08 ` Borislav Petkov
2013-07-23 21:44 ` Torsten Kaiser
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=20130724141927.GI30777@pd.tnic \
--to=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jacob.shin@amd.com \
--cc=johannes.hirte@fem.tu-ilmenau.de \
--cc=just.for.lkml@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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