On Sun, 08 Sep 2013, shirish शिरीष wrote: > microcode bundle 1: /lib/firmware/intel-ucode/06-17-0a > 01/001: sig 0x0001067a, pf mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192 > 01/002: sig 0x0001067a, pf mask 0x11, 2010-09-28, rev 0x0a0b, size 8192 > 01/003: sig 0x0001067a, pf mask 0x44, 2010-09-28, rev 0x0a0b, size 8192 > > The update is from one of these three binary files and as can be seen > the pf mask values of each of them are different.
Each of these apply to several processors. See below. > May I take this opportunity to add a wishlist bug. I would suggest to > add example commands. Like me there are many users who do not There are user-level example commands in the manpages, but for the regular stuff a normal user would need to do. > understand technicalities or manpage syntax/language per se. Giving > example commands should also help in broadening the reach of the > technology and its effectiveness. Regular users don't need to mess with iucode-tool, it does everything you need if you just give it "--scan-system" and point it to a file or directory with lots of microcodes inside ;-) intel-microcode uses iucode-tool automatically, without user interaction. Anything else does require that you actually grok very simple binary algebra, and also section 9.11 of that Intel document. A lot of what iucode-tool does is relevant only to people who need to mess with microcode colections, and that won't be a typical user. Basically: x86 processors have some registers related to the processor operation called MSRs. Intel processors have a *three-bit* field in MSR #17. This is called "platform id" and also "processor flags" by Intel. Since there is a cpuid(1) field that is also called "platform id" which is completely unrelated, I use "processor flags" in iucode-tool/intel-microcode. So, each processor has an "processor flags" ID that is between 0 and 7 (three bits). That ID is read from MSR 17. A byte has 8 bits, numbered from 0 to 7. So, an alternative representation of that "processor flags" ID is to set the respective bit in a byte. Let's call that "bitmask form". It is the *same* information, just represented in a different way (that takes 8 bits instead of 3 bits...). 0x prefix -> hexadecimal notation b suffix -> binary notation Processor Flags, MSR17 bit mask format 0 (000b) 0x00 1 (001b) 0x01 2 (010b) 0x02 3 (011b) 0x04 4 (100b) 0x10 .. .. 7 (111b) 0x80 That's the "pf=0xZZ" that the kernel informs. It is the "processor flags" in "bitmask format". Now, the microcode update has a "pf mask" field that has a bit set if the respective processor (i.e. one that bit as its "processor flags" in bitmask format") is compatible with that microcode update. In the data above about the available microcode updates for signature 0x1067a, you have: 01/001: sig 0x0001067a, pf mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192 This applies to processors with "pf=0x80" and "pf=0x20". 01/002: sig 0x0001067a, pf mask 0x11, 2010-09-28, rev 0x0a0b, size 8192 This applies to processors with "pf=0x10" and "pf=0x01". 01/003: sig 0x0001067a, pf mask 0x44, 2010-09-28, rev 0x0a0b, size 8192 This applies to processors with "pf=0x40" and "pf=0x04". pf=0x00 is special: it means the processor doesn't have a platform ID, so the processor will have pf=0x00, and the microcode updates will have a "pf mask" that is all zeros. In that case, only the signature matters. Well, I am not that a good teacher, but still I hope the above is a bit easier to understand than the Intel documentation. But I am not adding something that extensive to iucode-tool's manpage :-) And you really don't need to know any of that to use intel-microcode, it is supposed to do its job automatically. If it doesn't, that's a bug I will try to fix. -- "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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907232542.ga25...@khazad-dum.debian.net