Re: [PATCH 3.17 100/141] x86, microcode: Fix accessing dis_ucode_ldr on 32-bit

From: Boris Ostrovsky
Date: Wed Nov 26 2014 - 22:13:18 EST



----- bp@xxxxxxx wrote:

> On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote:
> > https://lkml.org/lkml/2014/11/25/973 is all I have right now.
>
> Ok, so the Code: section from this splat says:
>
> 25: 55 push %ebp
> 26: 89 e5 mov %esp,%ebp
> 28: 83 ec 08 sub $0x8,%esp
> 2b:* 80 3d c0 ee 97 01 00 cmpb $0x0,0x197eec0 <--
> trapping instruction
> 32: 89 1c 24 mov %ebx,(%esp)
> 35: 89 74 24 04 mov %esi,0x4(%esp)
> 39: 74 12 je 0x4d
> 3b: 8b 1c 24 mov (%esp),%ebx
> 3e: 8b .byte 0x8b
> 3f: 74 .byte 0x74
>
> which I can correlate to the dis_ucode_ldr test here:
>
> .loc 1 134 0
> .loc 1 137 0
> cmpb $0, dis_ucode_ldr+1073741824 #, *_11
> je .L46 #,
>
>
> so we must be faulting when accessing that dis_ucode_ldr thing. But
> you
> said that accessing it through its virtual address doesn't fix the
> issue
> either. Which is very very strange...


I was confusing you: accessing dis_ucode_ldr by virtual address does work on PV. But we then fail later, in load_ucode_intel_ap(), because it also tries to use __pa_nodebug() which can't be used by PV.

So if accessing dis_ucode_ldr by virtual address is acceptable (although I don't think it is?) then we can stick dis_ucode_ldr=1 into xen_start_kernel() and then things look OK.

A better solution may be to replace cpuid in x86_guest() with 'return pv_info.paravirt_enabled' (or paravirt_enabled(), I guess). I gave it a quick spin (32-bit only) and it seems to work. I'll see how my overnight tests behave.

-boris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/