Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jul 15, 2014 at 06:53:04PM +0100, Ben Hutchings wrote:
> On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote:
> > > On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > > > > Adding xen-devel and some of the Linux maints,
> > > > > 
> > > > > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > > > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > > > > 
> > > > > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > > > > - cgroups
> > > > > > - xen microcode
> > > > > > 
> > > > > > 
> > > > > > I consider both not a blocker, but would be happy if Xen guys could
> > > > > > have a look for what is needed.
> > > > > 
> > > > > The xen microcode patches which maks is referring to are these:
> > > > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > > > > which are a forward port of Jeremy's old microcode_xen.ko driver.
> > > > 
> > > > They are also at my branch
> > > > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> > > > 
> > > > Hm, I should rebase them at some point.
> > > > > 
> > > > > I've not been keeping up on Xen x86 microcode stuff these days but I
> > > > > think we don't need this any more with modern Xen since we can parse 
> > > > > the
> > > > > microcode blob off the front of the initrd, is that right?
> > > > 
> > > > Right. And best of it, the support for that is in dracut so
> > > > it automatically can happen (thought you still need to add
> > > > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > > > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> > > 
> > > Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
> > > initramfs-tools. So perhaps there is some work to be done here.
> > > 
> > > I understand ucode=scan, but what does the dracut option do?
> > 
> > Packages the blobs and sticks them to the initramfs.
> > 
> > I think 'initframfs-tools' will need some code there.
> [...]
> 
> initramfs-tools can already prepend microcode in the way Linux expects.
> I assume Xen supports the same format (it's a little weird for it to be
> parsing the dom0 initrd, but OK...).  But we're presumably missing the

It scans all of the binary blobs that are attached looking for the
proper cpio signature. So you could do it as a seperate cpio binary.

Or a binary blob (cat /lib/firmware/*ucode/* > /boot/multiboot.bin)
and the 'multiboot.bin' can be part of the multiboot stanza:
        module /multiboot.bin

And you add 'ucode=-1' for it to take the last module and use that
as its source of microcode code.

However, the 'ucode=scan' is more in line with what Linux has with
the early microcode loading so you are better of using that and
it will be less work.
> GRUB integration to get 'ucode=scan' added automatically.

<nods>
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Hoare's Law of Large Problems:
>         Inside every large problem is a small problem struggling to get out.



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