From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 26 Nov 2014 11:55:18 +0100 From: Borislav Petkov To: Boris Ostrovsky Cc: Konrad Rzeszutek Wilk , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Richard Hendershot , David Vrabel , x86-ml Subject: Re: [PATCH 3.17 100/141] x86, microcode: Fix accessing dis_ucode_ldr on 32-bit Message-ID: <20141126105517.GA29982@pd.tnic> References: <20141125184351.GC4128@pd.tnic> <5474D0A1.2020600@oracle.com> <20141125190849.GF4128@pd.tnic> <5474D86E.6020608@oracle.com> <20141125202628.GG4128@pd.tnic> <20141125203634.GA6433@laptop.dumpdata.com> <20141125211708.GH4128@pd.tnic> <5474FBC6.7090603@oracle.com> <20141125221800.GI4128@pd.tnic> <54755E7D.3060903@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54755E7D.3060903@oracle.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Wed, Nov 26, 2014 at 12:00:45AM -0500, Boris Ostrovsky wrote: > Sigh... I take this back. It breaks 32-bit baremetal. I haven't looked any > further but it seems to be dying very early. I suspect cpuid pv_op is not > set up yet. If that's true, perhaps you could check whether it is valid in > x86_guest()? Right, this is why we're using the native variants in the early loader. So we need a different method for detecting very early whether we're running as a guest. What I'd like more, though, is if we continue debugging the original issue where we fail in load_ucode_intel_ap(). Does it happen on this line: initrd_start_addr = (unsigned long)__pa_nodebug(*initrd_start_p); where we deref the initrd_start_p? Do you have a full splat with a Code: section? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --