From: Borislav Petkov <bp@suse.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable
Date: Tue, 2 Jun 2015 19:00:40 +0200 [thread overview]
Message-ID: <20150602170040.GE20576@pd.tnic> (raw)
In-Reply-To: <1433263793.26331.42.camel@linux.intel.com>
On Tue, Jun 02, 2015 at 07:49:53PM +0300, Andy Shevchenko wrote:
> Initial paging setup is involved?
Yes, load_ucode_bsp happens before paging is enabled on 32-bit. And
that should remain that way - we want microcode application as early as
possible.
> Hmm… which Intel CPUs you run on?
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
stepping : 9
microcode : 0x1b
and an SNB one too.
> Ah, one more thing we run our kernel from kexec (I hope it's not a
> case, but who knows).
Does it work when you boot a normal 32-bit kernel with builtin microcode
on it?
In order to load built-in microcode, you'll have to enable the boot
options in the commit message to
760d765b2bb6 ("x86/microcode: Parse built-in microcode early")
Let me know if something's not clear.
On Tue, Jun 02, 2015 at 07:46:29PM +0300, Andy Shevchenko wrote:
> > @@ -533,7 +533,12 @@ static bool __init load_builtin_intel_microcode(struct cpio_data *cp)
> > model = x86_model(eax);
> > stepping = eax & 0xf;
> >
> > - sprintf(name, "intel-ucode/%02x-%02x-%02x", family, model, stepping);
> > + *p++ = '/';
> > + p = hex_byte_pack(p, family);
> > + *p++ = '-';
> > + p = hex_byte_pack(p, model);
> > + *p++ = '-';
> > + p = hex_byte_pack(p, stepping);
> >
>
> Forgot to add *p = '\0'; here, but it doesn't really mater for the idea.
>
> What I would like to tell that if I move 'call load_ucode_bsp' after
> paging is done, it seems sprintf() starts working nicely.
Hmm, ok, so something's not able to stomach pre-paging. Can you dump
something from the failure, RIP, stack, whatever?
Can I reproduce it?
> So, I don't know which fix is better (or neither),
See above.
> and wondering if we need to fix AMD part.
No need, AFAICT. It did work in my testing.
> P.S. It would be really nice to get an expert / detailed explanation
> what is going on there.
Yeah, that's why I'm asking.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2015-06-02 17:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 14:56 [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable Andy Shevchenko
2015-06-02 16:24 ` Borislav Petkov
2015-06-02 16:49 ` Andy Shevchenko
2015-06-02 17:00 ` Borislav Petkov [this message]
2015-06-02 17:31 ` Andy Shevchenko
2015-06-03 10:56 ` Borislav Petkov
2015-06-03 15:27 ` Andy Shevchenko
2015-06-03 17:49 ` Shevchenko, Andriy
2015-06-03 21:13 ` Borislav Petkov
2015-06-04 9:21 ` [PATCH] x86/microcode: Disable builtin microcode loading on 32-bit for now Borislav Petkov
2015-06-04 9:47 ` Shevchenko, Andriy
2015-06-02 16:46 ` [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable Andy Shevchenko
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=20150602170040.GE20576@pd.tnic \
--to=bp@suse.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=mingo@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 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.