From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759796AbbFBRBA (ORCPT ); Tue, 2 Jun 2015 13:01:00 -0400 Received: from cantor2.suse.de ([195.135.220.15]:48882 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759758AbbFBRAu (ORCPT ); Tue, 2 Jun 2015 13:00:50 -0400 Date: Tue, 2 Jun 2015 19:00:40 +0200 From: Borislav Petkov To: Andy Shevchenko Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Mika Westerberg Subject: Re: [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable Message-ID: <20150602170040.GE20576@pd.tnic> References: <1433257003-159485-1-git-send-email-andriy.shevchenko@linux.intel.com> <20150602162403.GD20576@pd.tnic> <1433263793.26331.42.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1433263793.26331.42.camel@linux.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. --