Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932443AbcLOR1D (ORCPT ); Thu, 15 Dec 2016 12:27:03 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:32000 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757298AbcLOR1B (ORCPT ); Thu, 15 Dec 2016 12:27:01 -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> Cc: Juergen Gross , Linux Kernel Mailing List , xen-devel From: Boris Ostrovsky Message-ID: Date: Thu, 15 Dec 2016 12:27:49 -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: <20161215171755.xpfuax7a6q3jofet@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1347 Lines: 44 On 12/15/2016 12:17 PM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote: >> There is an error on AMD as well. We end up being called at >> load_microcode_amd() with size=0 and crash soon after. > Does that fix it? > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index dd47e60aabf5..e238119b5dff 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1202,6 +1202,7 @@ config X86_REBOOTFIXUPS > config MICROCODE > bool "CPU microcode loading support" > default y > + depends on !XEN > depends on CPU_SUP_AMD || CPU_SUP_INTEL > select FW_LOADER > ---help--- It will probably fix it but I don't think we want this: it's a build-time solution. Most kernels have XEN on even though they are booted bare-metal. > >> (As a side note, I think verify_and_add_patch() should return error >> codes and not crnt_size, which may be a positive number. Which it was in >> my case.) > It does return negative values when there's some failure. I meant, for example: proc_fam = find_cpu_family_by_equiv_cpu(proc_id); if (!proc_fam) { pr_err("No patch family for equiv ID: 0x%04x\n", proc_id); return crnt_size; } -boris > It returns > crnt_size which can be a positive number so that we can advance to the > next patch in the blob. >