Messages in this thread | | | Date | Wed, 13 Jun 2012 11:01:14 -0300 | From | Henrique de Moraes Holschuh <> | Subject | Re: [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge |
| |
On Wed, 13 Jun 2012, Peter Zijlstra wrote: > On Tue, 2012-06-12 at 13:42 -0700, H. Peter Anvin wrote: > > And yes, I would prefer a single sysfs file, > > or better yet a plain old device node. > > So how about we rip out all this sysfs crap and go back to > MICROCODE_OLD_INTERFACE ? Afaict that's relatively sane.
Please teach it to handle partial writes kernel side, so that we can just use "cat" in userspace instead of special tools (or nasty hacks using 'dd'), then. And it would be a bit annoying for userspace to figure out whether it wants Intel or AMD or <whatever vendor> microcode...
IMHO, if we fix the firmware interface to the microcode core, it can do a lot better than MICROCODE_OLD_INTERFACE, and it can integrate very well with userspace.
"Fixing" the microcode firmware interface (i.e. making it optimal from userspace's PoV) is not a complex endeavour:
1. Add the per-system sysfs node, and drop the per-core nodes for firmware updates. I understand this _will_ be done anyway because the current status-quo is dangerous.
2. Add a cache layer, so that microcode files are fetched only once per file per update cycle, no matter how many cores [optional, but quite welcome as it speeds up the boot]
3. Change the Intel firmware naming convention to a constant name, instead of the variable naming scheme currently used. This can be done in a backwards compatible way, by attempting to load the variable named firmware file if the first attempt fails.
4. Declare proper MODULE_FIRMWARE() and auto-load information.
With all that, all we'd have to do in the distros would be to ship binary processor microcode the very same way we already deal with firmware for everything else.
BTW, I've uploaded to Debian a tool that can actually manipulate the Intel microcode container well enough to help Debian do some release management[1], and helps the user have tailored, per-system reduced microcode files. The code is probably crap as far as LKML standards for C code go, but if there's general interest, I can make the upstream git tree public in gitorious or something. Full source currently available in the ".orig.tar.bz2" file of the Debian source package:
http://packages.qa.debian.org/i/iucode-tool.html http://cdn.debian.net/debian/pool/contrib/i/iucode-tool/ http://cdn.debian.net/debian/pool/contrib/i/iucode-tool/iucode-tool_0.8.orig.tar.bz2
[1] Maybe Intel could actually consider making it easier to the general Linux distro and Linux admin/power user, and provide a proper chagelog along with its microcode dumps? AMD does it, and it *really* helps... A timeline of the microcodes shipped by Intel paints an EXTREMELY confusing picture.
-- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
| |