Specs of the AMD machine:

processor       : 7
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD FX(tm)-8320 Eight-Core Processor           
stepping        : 0
microcode       : 0x6000822
cpu MHz         : 3511.804
cache size      : 2048 KB

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: M5A97 LE R2.0
        Version: Rev 1.xx

Pass 'dis_ucode_ldr' on the command line and see if that makes the issue go away.  This isn't a properly solution but it might suffice as a workaround.  I'd suggest taking the problem report upstream as well.

(In reply to Josh Boyer from comment #2)
> Pass 'dis_ucode_ldr' on the command line and see if that makes the issue go
> away.  This isn't a properly solution but it might suffice as a workaround. 
> I'd suggest taking the problem report upstream as well.

That did it.
Trying different builds to see what CONFIG option exposes this as I don't seem to be triggering it with my normal builds.

It could just be a case of the initramfs being too large for the memory allocated to your guest.  We enabled early microcode loading a while ago, which means the ucode gets prepended to the initramfs image.  Does increasing the memory to the guest also make it boot?

Here's what the asm looks like after Josh pointed me at the kernel in
question (btw, there's another bug - 1157157 - which has the same RIP).
Annotations mine reconstructed from System.map:

c042e8e0 <load_microcode_amd>:
c042e8e0:       55                      push   %ebp
c042e8e1:       89 e5                   mov    %esp,%ebp
c042e8e3:       57                      push   %edi
c042e8e4:       56                      push   %esi
c042e8e5:       53                      push   %ebx			# ... callee-saved
c042e8e6:       83 e4 f8                and    $0xfffffff8,%esp		# align stack ptr
c042e8e9:       83 ec 2c                sub    $0x2c,%esp		# grow stack
c042e8ec:       e8 4b 68 61 00          call   0xc0a4513c		# mcount
c042e8f1:       88 44 24 1f             mov    %al,0x1f(%esp)
c042e8f5:       a1 cc d8 e3 c0          mov    0xc0e3d8cc,%eax		# equiv_cpu_table
c042e8fa:       89 d7                   mov    %edx,%edi		# data
c042e8fc:       89 4c 24 28             mov    %ecx,0x28(%esp)
c042e900:       e8 4b 7d 13 00          call   0xc0566650		# vfree()
c042e905:       8b 77 08                mov    0x8(%edi),%esi		<--- faulting insn
c042e908:       c7 05 cc d8 e3 c0 00    movl   $0x0,0xc0e3d8cc
c042e90f:       00 00 00

%edi (copied from %edx) contains the second arg to apply_microcode_amd()
which is that that const u8 *data pointer, pointing to the microcode
container coming from the initrd. And that %edi looks funny: 0x35d4e2fc
which causes the NULL ptr deref.

And since save_microcode_in_initrd_amd() checks the container for being
0, it is probably that relocated_ramdisk fun we do which gets the
container pointer wrong.

Konrad, can you dump those values participating in the computation? It
might tell us what is going wrong:

        if (relocated_ramdisk)
                container = (u8 *)(__va(relocated_ramdisk) +
                             (cont - boot_params.hdr.ramdisk_image));

Thanks.

Created attachment 952289 [details]
serial console with the crash

Created attachment 952290 [details]
The patch I used.

Ugh. Time to add more printks..

Created attachment 952526 [details]
serial console with the crash

The issue appears to be in:

 	ret = load_microcode_amd(eax, container, container_size);

Created attachment 952527 [details]
Debug patch

(In reply to Konrad Rzeszutek Wilk from comment #9)
> The issue appears to be in:
> 
>  	ret = load_microcode_amd(eax, container, container_size);

Yeah, I thought this was clear from comment #5...

In any case, staring at this more, it looks like this happens because
we're using the *physical* address of the container *after* we have
enabled paging and thus the #PF. Because the ramdisk is exactly there:

[    0.000000] RAMDISK: [mem 0x35e04000-0x36ef9fff]

and we fault at 0x35e04304.

And since this guest doesn't relocate the ramdisk, we don't do the
computation which will give us the correct virtual address and we end up
with the PA.

So, we should actually be using virtual addresses on 32-bit by the time
we're freeing the initrd. How about the attached debug patch?

Thanks.

Created attachment 952535 [details]
test patch

Created attachment 952587 [details]
console with your patch

(In reply to Konrad Rzeszutek Wilk from comment #13)
> Created attachment 952587 [details]
> console with your patch

Which of course boots!

Thanks for testing Konrad, much appreciated. I'll clean it up and send it to tip guys soon.

@Josh: you can close this one now.

Thanks.

Will be in todays 3.18.0-0.rc3.git0.1 build.  Thanks Borislav!