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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

----- bp@suse.de 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