Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Mon, Aug 04, 2014 at 03:40:45PM +0100, Jan Beulich wrote:
> >>> On 04.08.14 at 16:07, <konrad.wilk@oracle.com> wrote:
> > On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
> >> >>> On 15.07.14 at 16:59, <konrad.wilk@oracle.com> 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
>
Reply to: