Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756907AbcLOWzk convert rfc822-to-8bit (ORCPT ); Thu, 15 Dec 2016 17:55:40 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:16726 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756552AbcLOWzi (ORCPT ); Thu, 15 Dec 2016 17:55:38 -0500 Subject: Re: Can't boot as Xen dom0 due to commit fe055896 To: Borislav Petkov References: <73a4d64b-b139-6579-a560-92311641d6c7@suse.com> <20161215164635.thm7ruio2ddnxszw@pd.tnic> <20161215171755.xpfuax7a6q3jofet@pd.tnic> <20161215173609.ornfok6lk5oro2pj@pd.tnic> <385ac3cd-7a3f-4c4d-69bb-8feee235fb7e@oracle.com> <20161215192305.dlgyrmteirgzop4y@pd.tnic> <399c758a-a94b-8aa1-efbb-79a0161b8020@oracle.com> <20161215200324.6ju7o5e3aiirrycf@pd.tnic> Cc: Juergen Gross , Linux Kernel Mailing List , xen-devel From: Boris Ostrovsky Message-ID: <51f0a58d-a5bc-aae4-22b2-f45bf7164088@oracle.com> Date: Thu, 15 Dec 2016 17:56:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161215200324.6ju7o5e3aiirrycf@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2262 Lines: 59 On 12/15/2016 03:03 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote: >> We are calling find_proper_container(..., &eq_id) and determine result >> based on eq_id not being zero. If find_proper_container() doesn't find >> anything it will not modify eq_id and so you get back whatever you >> passed in. > The correct fix for that is to not return struct container at all from > those functions but simply an eq_id or even an int error value or so. > Passing back a struct is simply silly. I'll prep a proper patch for > that. > >> The fact that I am having problems with HVM may or may not have >> anything to do with microcode. I don't know yet but it's separate from >> save_microcode_in_initrd_amd() patch. I am pretty sure about that >> because unlike PV it is failing in early boot code. For AMD you also need something like: --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -297,6 +297,7 @@ void __init load_ucode_amd_bsp(unsigned int family) struct cpio_data cp; const char *path; bool use_pa; + u32 eax = 1, ebx, ecx = 0, edx; if (IS_ENABLED(CONFIG_X86_32)) { uci = (struct ucode_cpu_info *)__pa_nodebug(ucode_cpu_info); @@ -315,7 +316,8 @@ void __init load_ucode_amd_bsp(unsigned int family) return; /* Get BSP's CPUID.EAX(1), needed in load_microcode_amd() */ - uci->cpu_sig.sig = cpuid_eax(1); + native_cpuid(&eax, &ebx, &ecx, &edx); + uci->cpu_sig.sig = eax; apply_microcode_early_amd(cp.data, cp.size, true); } With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a call via a pointer, you can see it, for example, if you disassemble load_ucode_amd_bsp(). And we don't have paging on yet when we call load_ucode_amd_bsp (at least in 32-bit mode). > I still need a fix for Jürgen's use case where he lands in the > microcode loader. And that he shouldn't do in the first place when > running in a xen guest. > Since this happens during AP bringup PV cpuid is available and can be checked to see whether we are a guest. But I think it may be worthwhile trying to understand why we are dying, it hasn't happened until now. -boris