[lkml]   [2016]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Can't boot as Xen dom0 due to commit fe055896
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.)


 \ /
  Last update: 2016-12-15 17:58    [W:0.067 / U:2.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site