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 15:41:30 +0200 [thread overview]
Message-ID: <20130724134130.GF30777@pd.tnic> (raw)
In-Reply-To: <CAPVoSvR30mjRq8Kcp34akb6R1oTi4Y+z7CCO_8FWK5cGd-W61A@mail.gmail.com>
Let me try to answer this as well as I can, peacemeal-wise.
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov <bp@alien8.de> wrote:
> > On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
> >> Fixup the early AMD microcode loading.
> >>
> >> * load_microcode_amd() (and the helper its using) should not have an
> >> cpu parameter.
> >
> > Hmm, I don't think so - we get the cpu handed down from microcode_core
> > and besides the early load on 32bit needs to do find_patch(cpu).
>
> Thats why I moved that part into apply_microcode_amd(). See later on
> more, why I think that move is the right thing.
> And without that the current cpu parameter will only be used to get
> the (in the early load case not even correctly set up!) per-cpu data.
> But the only member of cpuinfo_x86 that gets uses is ->x86, the family.
> Line 159: switch(c->x86) and Line 301: if (proc_fam!)c->x86)
>
> I really wanted to make that switch from cpu to x86family a separate
> patch, that it would be more obvious correct, but because of that
> amd_bsp_mpb hunk I can't find a good cut and thats why this patch is
> larger that I would have preferred.
Ok.
> >> The microcode loading is not depending on the CPU it is
> >
> > Mostly. There are mixed-stepping boxes which need to differentiate
> > between which cpu we're applying the patch for.
>
> Nothing looks at ->x86_model or ->x86_mask during load.
> It will always load all patches from the current family.
Yes, that's the idea. We want to have all patches for the current family
loaded.
> If loading would really depend on the current cpu in a mixed
> system that would be horrible: Depending on which CPU gets execute
> load_microcode_amd() it there would be different patches loaded into
> RAM?
No, we load the microcode based on CPUID(1).EAX which is in the
equivalence table. Look at find_equiv_id().
But for that we need all patches belonging to the current family to be
in the cache.
> > Btw, your config boots on my F14h box with "nomodeset" on the command
> > line because it is missing radeon firmware for my gpu.
>
> I suspect a F14h box will never see that hang. It trips over the the
> C1E erratum and amd_erratum_400[] looks like it only affects 0xfh and
> 0x10h (like my Phenom II X6).
I could fire up my F10h if needed :)
> >> executed and all the loaded patches will end up in a global list for all
> >> CPUs anyway.
> >> * Return -1 (like Intels apply_microcode) when the loading fails,
> >> also do not set the active microcode level on failure.
> >
> > Yep, this part I want. Please send it as a separate patch.
>
> OK, will send that together with the resend for cpu_has_amd_erratum().
Ok.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-07-24 13:41 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 [this message]
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
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=20130724134130.GF30777@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.