[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161215164635.thm7ruio2ddnxszw@pd.tnic>
Date: Thu, 15 Dec 2016 17:46:35 +0100
From: Borislav Petkov <bp@...e.de>
To: Juergen Gross <jgross@...e.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
xen-devel <xen-devel@...ts.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: Can't boot as Xen dom0 due to commit fe055896
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...
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists