Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758393AbcLOQ55 convert rfc822-to-8bit (ORCPT ); Thu, 15 Dec 2016 11:57:57 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:47002 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751955AbcLOQ54 (ORCPT ); Thu, 15 Dec 2016 11:57:56 -0500 Subject: Re: Can't boot as Xen dom0 due to commit fe055896 To: Borislav Petkov , Juergen Gross References: <73a4d64b-b139-6579-a560-92311641d6c7@suse.com> <20161215164635.thm7ruio2ddnxszw@pd.tnic> Cc: Linux Kernel Mailing List , xen-devel From: Boris Ostrovsky Message-ID: Date: Thu, 15 Dec 2016 12:00:22 -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: <20161215164635.thm7ruio2ddnxszw@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1582 Lines: 46 On 12/15/2016 11:46 AM, Borislav Petkov wrote: > On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >> with today's kernel the system isn't coming up when booted as Xen dom0: > Remind me again pls, is dom0 even supposed to load microcode? Isn't the > hypervisor supposed to apply microcode? > >> Looking into the state of cpu 1 I find the following backtrace (created >> manually by looking up addresses from a stack dump retrieved from the >> hypervisor): >> >> find_cpio_data() >> find_microcode_in_initrd() >> __load_ucode_intel() >> load_ucode_intel_ap() >> cpu_init() >> cpu_bringup() >> cpu_bringup_and_idle() >> >> It seems as if load_ucode_intel_ap() is looping. You introduced a >> possibly endless loop in it with commit fe055896. > Are you sure you mean: > > fe055896c040 ("x86/microcode: Merge the early microcode loader") > > because that commit is a year old. > > So from looking at the *current* code: > > if (apply_microcode_early(&uci, true)) { > > fails probably because MSR_IA32_UCODE_REV doesn't get read properly due > to virtualized MSRs, bla, yadda yadda... > > But before we debug this further, I'd like to make sure I'm debugging > the proper thing and not some situation again where xen wasn't even > supposed to run the microcode loader but it does it anyway... > There is an error on AMD as well. We end up being called at load_microcode_amd() with size=0 and crash soon after. (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.) -boris