Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
> 
> 
> Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
> [snip]
> >>The maintainer is being <insert your own opinion here>:
> >>  - runtime microcode. What I had been told was to use the 'early
> >>    microcode' mechanism - which is now implemented and Xen can also scan
> >>    the initramfs to extract the microcode payload and apply it.
> >
> >I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> >modules works pretty well.
> >
> >>    But it misses the important part of server longevity in that the
> >>    host might be running for years and the microcode might need to be
> >>    updated during that time. bpetkov wasn't too thrilled about the
> >>    runtime microcode and I hadn't come back to this yet to figure out
> >>    what are his exact technical misgivings.
> >
> >I think, in the end, he (and Ingo) were advocating just doing a full
> >emulation of the Intel/AMD update mechanism in the set/getmsr PV
> >callbacks. Which is doable but... well, not pretty. Maybe a new attempt
> >with get a new reception.
> 
> I can add my experience from the perspective of a user trying to get
> early microcode loading to work with my system:
> 
> First of all I can confirm that it sort of works - but as Jeremy has
> pointed out, there seem to be issues with including it into the
> initramfs. After many unsuccessful tries I also only got it to work
> when I used a separate entry in multiboot (grub2) which referred to
> the blob for uploading the payload to the CPU.
> 
> As soon as I had the microcode integrated into the initramfs as
> described at
> http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
> the system would no longer boot with a message stating that it could
> not find the root filesystem - I assume that was at the time when
> the initramfs was about to be unpacked and loaded (if I recall
> correctly there were no messages from the initramfs on screen).
> Therefore I couldn't verify whether the microcode was actually
> lodaded before that.

Hm, that would imply that Linux couldn't skip past the 'non-gzip'
payload of the initramfs. But it does work for me so I am wondering
what I am doing differently.

Could you send an email with your .config and perhaps your serial log
if you still have it?


> 
> My feeling at that time was that the unpacking of the initramfs had
> failed and it was probably more a linux issue rather than a XEN
> issue - albeit the concatenated file which per the link above should
> be created by
> 
> "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
> 
> does not resemble a valid cpio archive any longer (you also can't
> work with it on the command line - e.g. list its content). I assume
> that though the kernel expects a valid cpio format file and
> therefore is unable to unpack and subsequently fails.

It should skip the bits that it does not understand.
> 
> But in any case, with the additional file in multiboot it works
> flawlessly. The only catch is that the file distributed by Intel
> (the microcode.dat which is a text file) has to be converted inot a
> binary file (I also stripped it down to only contain the parts
> necessary for my CPU, but I don't know whether that's strictly
> necessary). And it must _NOT_ be a cpio archive in that case.

You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
and that would do it too.

> 
> Searching google there are a few tools available to convert the
> Intel distributed microcode.dat to binary format and reduce it to
> only the parts required for a specific CPU.
> 
> Regards Atom2