From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756113AbbFCVON (ORCPT ); Wed, 3 Jun 2015 17:14:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47614 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754545AbbFCVOE (ORCPT ); Wed, 3 Jun 2015 17:14:04 -0400 Date: Wed, 3 Jun 2015 23:13:52 +0200 From: Borislav Petkov To: "Shevchenko, Andriy" Cc: "andy.shevchenko@gmail.com" , "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "mika.westerberg@linux.intel.com" Subject: Re: [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable Message-ID: <20150603211352.GC4706@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> <20150602170040.GE20576@pd.tnic> <20150603105640.GA4706@pd.tnic> <1433345266.26331.57.camel@linux.intel.com> <1433353745.26331.58.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1433353745.26331.58.camel@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 Wed, Jun 03, 2015 at 05:49:05PM +0000, Shevchenko, Andriy wrote: > On Wed, 2015-06-03 at 18:27 +0300, Andy Shevchenko wrote: > > > > I have a totally empty screen (serial console). So, if you teach me > > > > how to gather that I could do it later on. > > > > > > That'll be hard - you'd probably need a hardware debugger or something > > > special to get a RIP or other data that early... Or hack up some very > > > early console printing with BIOS methods and so on. hpa had something > > > like that somewhere AFAIR... > > > > I could try kvm / qemu as well, though there might be not the same > > conditions. > > Yeah, qemu runs fine. So, I did some more experiments and even if we build the string properly, we choke later in get_builtin_firmware(). Actually, we don't choke but we don't find firwmare because we're running with physical addresses and those __start/__stop_builtin_fw things are virtual addresses. Yuck! So I'm gravitating towards disabling builtin microcode loading on 32-bit. For now, as the merge window is going to be open soon, until we/I have fixed it properly. And I don't have a clear solution now - all I can think of is ugly ifdeffery which I'd like to avoid. Grrr. --- diff --git a/arch/x86/kernel/cpu/microcode/amd_early.c b/arch/x86/kernel/cpu/microcode/amd_early.c index 9208a36d0f03..9243cd839829 100644 --- a/arch/x86/kernel/cpu/microcode/amd_early.c +++ b/arch/x86/kernel/cpu/microcode/amd_early.c @@ -230,6 +230,7 @@ static void apply_ucode_in_initrd(void *ucode, size_t size, bool save_patch) static bool __init load_builtin_amd_microcode(struct cpio_data *cp, int family) { +#ifdef CONFIG_X86_64 char fw_name[36] = "amd-ucode/microcode_amd.bin"; if (family >= 0x15) @@ -237,6 +238,9 @@ static bool __init load_builtin_amd_microcode(struct cpio_data *cp, int family) "amd-ucode/microcode_amd_fam%.2xh.bin", family); return get_builtin_firmware(cp, fw_name); +#else + return false; +#endif } void __init load_ucode_amd_bsp(int family) diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c b/arch/x86/kernel/cpu/microcode/intel_early.c index 10dff3f3f686..b4858d892592 100644 --- a/arch/x86/kernel/cpu/microcode/intel_early.c +++ b/arch/x86/kernel/cpu/microcode/intel_early.c @@ -523,6 +523,7 @@ EXPORT_SYMBOL_GPL(save_mc_for_early); static bool __init load_builtin_intel_microcode(struct cpio_data *cp) { +#ifdef CONFIG_X86_64 u32 eax = 0x00000001, ebx, ecx = 0, edx; int family, model, stepping; char name[30]; @@ -536,6 +537,9 @@ static bool __init load_builtin_intel_microcode(struct cpio_data *cp) sprintf(name, "intel-ucode/%02x-%02x-%02x", family, model, stepping); return get_builtin_firmware(cp, name); +#else + return false; +#endif } static __initdata char ucode_name[] = "kernel/x86/microcode/GenuineIntel.bin"; -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --