Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New WorldOrder firmware...

From: Giacomo A. Catenazzi
Date: Thu Jul 03 2008 - 12:22:53 EST


[recipient clean-up and adding Simon]

David Woodhouse wrote:
On Thu, 2008-07-03 at 06:56 -0700, Arjan van de Ven wrote:
On Thu, 03 Jul 2008 11:24:34 +0200
"Giacomo A. Catenazzi" <cate@xxxxxxxxxx> wrote:

Actually there are three:

1. The text format 'microcode.dat', including updates for all CPUs.
2. The binary format output by microcode_ctl, still including all CPUs.
3. The smaller files with just the relevant subset of #2.

we are diverging :-(

The #2 is not on upstream microcode_ctl. BTW Debian/Ubuntu already
diverge a lot in respect of upstream.
Further, IIRC, Simon slowed/stopped developing microcode_ctl, because
he think (IIRC) that distributions used other solutions or going to
use #3.

So if we need #2, I really want Simon (or someone) that take care
of continuing microcode_ctl upstream and merging distribution
patches.

The kernel (since 2006) can actually take either #2 or #3. The udev
scripts I just posted will use microcode_ctl to feed it #2, when they
find #1 on the file system.


#1 and #2 have some problem in Debian/Ubuntu:
- microcode_ctl is in /usr
- it require a module, so we load the module and we wait that
the device is created (it is asynchronous)
- initram would require an additional program, to an early load
- split on architectures [32/64bit CPU] (but this is an internal
autobuild / non-free Debian problem)


A small amount of extra work in the userspace tool would let those udev
scripts feed #3 to the kernel, and then the code in the kernel to select
the appropriate update could be removed.

I don't think Intel want this solution.
Earlier Intel preferred to give us two version of microcode
(new and old kernel) instead of let us to filter out one
short microcode, which trigged a kernel bug.

I'm ready to do such script (really I've already
a similar tool)



Actually Intel provides only the old methods.
There was talks with Arjan and Intel about the distribution format
for the new methods. But I don't have any new.
I think that when the new format is fully specified (directory
structure, tar, gzip,...) Intel will distribute the microcodes
in the new form.

Doesn't the "new format" (#3) involve hard links too, since there are
some cases where the same microcode update applies to more than one CPU
revision?

no, I don't think. Intel documentation on BIOS writing, document
that microcode should be discarded if the header information don't
match with current CPU. I didn't checked if some microcode
contains same data with different header (which anyway is not feeded
to the CPU)


we hope to switch to the new form but there's the small case of
"installed base" using ancient kernels, and it's kind of not nice to
have to release 2 sets. At some point we will switch over though.

Do we really need to _ship_ it in a different form? It's not exactly
hard to convert from the text form (#1) to either of the other two --
either on the fly in udev scripts, or at installation time.

It was a personal interpretation of Intel wishes.

ciao
cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/