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

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

On Mon, Aug 04, 2014 at 03:40:45PM +0100, Jan Beulich wrote:
> >>> On 04.08.14 at 16:07, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
> >> >>> On 15.07.14 at 16:59, <konrad.wilk@xxxxxxxxxx> 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/feat
> >  
> > 
> >> > ures/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/mis
> >  
> >> > c
> >> > 
> >> > 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'.
> >> 
> >> Except that all this still doesn't take care of updating microcode at
> >> runtime. Yet that should - like kexec - be implemented in the
> >> respective tools such that no kernel involvement it required.
> > 
> > What are such tools?
> 
> Wasn't there a microcode_ctl tool/package?

There was but it is obsolete:

***************************************************************************
>>> What it does
***************************************************************************
Deploy an Intel and AMD microcode. This tool is obsolete and the microcode
is the subject to be distributed via kernel-firmware, however Intel still
does not supply the microcode in a form consumable by the Linux's microcode

> 
> > My recollection is that it is matter of
> > sticking the files in /lib/firmware and then udev - will try
> > at the detection of an CPU becoming online, do:
> >  - load microcode module
> >  - echo 1 > to the 'reload' sysfs parameter
> > 
> > Perhaps the solution is simple:
> >  - write an xen userspace tool that will do this loading via
> >    the hypercalls.
> >  - plug said tool in the udev script that comes with xen.
> >  - distros will install said udev scripts when they install Xen rpms?
> > 
> > That sounds too simple to be true. I must be missing something :-)
> 
> That would be an option too (namely if, say, the microcode_ctl tool
> is considered deprecated/dead), and indeed can't be very difficult.

Vacation does wonders for ones brain! I shall put it on the TODO list.
thank you!
> 
> Jan
> 

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