All of lore.kernel.org
 help / color / mirror / Atom feed
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.
--

  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.