Re: [Xen-users] ucode=-1: did anybody have success?

[Atom2 <ariel.atom2@xxxxxxxxxx>]

Am 06.05.14 15:27, schrieb Sven Köhler:
> Hi,
>
> does anybody use Xen's ucode=-1 option successfully?
> I'm trying to update the microcode before dom0 starts, since my dom0
> doesn't have the xen microcode driver. I'm using a vanilla 3.12.x kernel
> from kernel.org and to the best of my knowledge, the xen microcode
> kernel driver didn't make it upstream yet.
It took me quiet some time as well to figure out how to get it to work, 
but I finally sorted it out some time ago.
> So I'd like to use ucode=-1 since I don't use any initrd. The
> documentation is speaking of a CPU microcode update BLOB that I need to
> add to my GRUB configuration as a module. But: BLOB in which format?
It requires a binary format - see further below.
> Well, on my system the microcode exists in two formats:
> - /lib/firmware/microcode.dat (not sure what the format is, it's
> definitely not cpio based, as would be needed for ucode=scan)
> - many single files in /lib/firmware/intel-ucode/
>
>
> Which line in grub would be correct? I guess it isn't
>    module /lib/firmware/microcode.dat
> or
>    module /lib/firmware/intel-ucode/<somefile>
> by any chance?
I can only advise for grub2 but I assume legacy grub should have similar 
options. For grub2 I use the following structure and that works very 
well - although my system does require an initrd as I use btrfs RAID1 
for my dom0 root file system. Without an initrd I would expect that you 
just leave out the two lines I have marked in square brackets (i.e. 
"echo 'Loading ..." and "module /initrd..."):
multiboot  /xen-4.3.1.gz placeholder ucode=-1 <more options>
echo       'Loading Linux 3.13.6-hardened-r3 ...'
module     /vmlinuz-3.13.6-hardened-r3 placeholder root=... <more opts>
[echo      'Loading initial ramdisk ...']
[module    /initrd-3.13.6-hardened-r3.gz]
module     /microcode.bin

Note that for this approach you can use any name for the binary blob 
file - you are not bound to use GenuineIntel.bin. The file named 
microcode.bin contains the binary microcode update blob; see further 
below how to create that.
> Now the documentation of ucode goes on to talk about some file
> called kernel/x86/microcode/GenuineIntel.bin. But it only talks about it
> in combination with ucode=scan.
If you use it in an initrd it must have that path/file name combination 
and be in cpio format (NOTE: you MUST use 'cpio -H newc' to create the 
cpio file and not 'cpio -o c' as some information on the internet 
suggests) which is prepended to the initrd for it the to be recognized. 
Also note that this approach requires XEN 4.4 or higher.
> A wild guess could be, that this file is
> identical to microcode.dat.
No it isn't ...
> Another wild guess could be, that this file
> is something I have to download from intel,
No you can't ...
> and this is also the file I
> have to use as a module in case I'm using ucode=-1 instead of ucode=-1.
Yes it is ...
> Or maybe the file is taken from /lib/firmware/intel-ucode/ and is copied
> to the initrd when it is updates?
The truth is that you can't use the microcode.dat file directly - this 
is a text file whereas the CPU expects a binary file. You should be able 
to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
and that should do it - although I have used another approach that 
results in a much smaller blob file: My file is now onyl 10,240 bytes as 
opposed to 576,512 bytes compared to cat /lib/firmware/... as described 
above) as it only contains the required binary files for my specific CPU:
I have used a tool called 'iucode-tool' to convert the Intel 
distribution files to the blob binary file (I decided to name it 
microcode.bin and that's what I use in the module line above). This tool 
has a number of options that allow to include only those parts of the 
microcode patches that are required for your specific CPU model (it is 
able to scan for your CPU or you can provide the model as a command line 
argument)
Your best bet is to check whether your distribution offers iucode-tool 
and install it. Failing this you can also download the source and 
compile it (I had to do this for gentoo) - that was pretty easy.
Hope this helps,

Atom2
> So could somebody who did all the research and experimenting present his
> working configuration?
>
> I think I tried microcode.dat once, and it didn't seem to work.
> I haven't tried a file from /lib/firmware/intel-ucode/ as I only have
> one production system and my test system is a VM where microcode updates
> are not possible.
>
>
> Regards,
>    Sven
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users