Re: [PATCH] x86, microcode: Make reload interface per system

[Borislav Petkov <bp@amd64.org>]

On Mon, Jun 18, 2012 at 08:31:08PM -0700, H. Peter Anvin wrote:
> On 06/18/2012 07:46 PM, Henrique de Moraes Holschuh wrote:
> > 
> > It is a pity this one is much harder to backport to 3.2 and 3.0.  I'd
> > really like to have the new interface there.  But it looks good, and we
> > will support the new /sys/devices/system/cpu/microcode/reload sysfs node
> > in Debian for the benefit of anyone using a newer kernel than the
> > distro's (which will be based on 3.2).
> > 
> > So, fwiw, you have my:
> > Acked-by-unimportant-person: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> > 
> 
> I have to admit to being slightly questioning to the whole "sysfs
> trigger, request_firmware" interface... it seems royally backwards to me
> (it makes sense for the initial firmware load, I guess, but that is
> better done early.)

Two reasons:

1. There are those guys who like to run their systems for years without
upgrading the kernel (you know who you are :)) and in such cases, you
want to be able to upgrade the microcode you loaded early with a newer
version which the hw vendor released in the meantime.

 [ Which makes the whole ucode-load-early deal not the solution to all
 problems since we need to be able to load ucode without rebooting too,
 if possible. ]

2. Right, we can do that by

$ rmmod microcode; modprobe microcode

but then the same guys come :-) and say they don't want to reload
modules for security reasons.

Thus the sysfs interface and sysfs is the proper thing we have for such
things so ...

... and I'm always open for better ideas, btw.

> Either way I don't have a hugely strong preference.

I'll run the patches here and send them out maybe later today if all
looks good.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551