Re: [Xen-devel] How many patches are missing in upstream Linux?

[Atom2 <ariel.atom2@xxxxxxxxxx>]

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.
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.
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.
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel