Date: Thu, 18 Jan 2018 19:08:40 +0100 From: Andre Albsmeier <andre@fbsd.e4m.org> To: Sean Bruno <sbruno@freebsd.org> Cc: Andre Albsmeier <andre@fbsd.e4m.org>, svn-ports-head@freebsd.org Subject: Re: svn commit: r459266 - in head/sysutils/devcpu-data: . files Message-ID: <20180118180840.GA41197@voyager> In-Reply-To: <2f342782-b5e2-e424-40ba-19b63532675f@freebsd.org> References: <201801171604.w0HG4Swh054032@repo.freebsd.org> <20180118170358.GA11507@voyager> <2f342782-b5e2-e424-40ba-19b63532675f@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18-Jan-2018 at 10:06:29 -0700, Sean Bruno wrote: > > > On 01/18/18 10:03, Andre Albsmeier wrote: > > On Wed, 17-Jan-2018 at 16:04:28 +0000, Sean Bruno wrote: > >> Author: sbruno > >> Date: Wed Jan 17 16:04:27 2018 > >> New Revision: 459266 > >> URL: https://svnweb.freebsd.org/changeset/ports/459266 > >> > >> Log: > >> sysutils/devcpu-data: Migrate our microcode update on Intel to use precreated files. > >> > >> Intel provides prefabricated per-cpu microcode update files. We no longer need > >> a tool to extract them from the legacy microcode.dat store. This matches > >> what upstream linux distributions are doing now. Tested on my Intel machines > > > > Hmm, the old mechanism gave me 169 files while this new one gives > > me only 99. On the other hand, the file > > > > -rw-r----- 1 andre andre 6144 18 Jan 17:40 0f-02-07 > > > > from the new one, is the concatenation of > > > > -rw-r----- 1 andre andre 2048 18 Jan 17:41 m02f2738.fw > > -rw-r----- 1 andre andre 2048 18 Jan 17:41 m04f2737.fw > > -rw-r----- 1 andre andre 2048 18 Jan 17:42 m08f2739.fw > > > > from the old one (there are more files like this). However, I wonder > > if feeding cpucontrol with 0f-02-07 on a machine which formerly had > > been patched using m04f2737.fw will still work. > > > > > That's the general idea, yes. We did a quick audit in the review and it > seems to be that way. Yes, but I am unsure if our cpucontrol will handle this. I had a quick(!) look at intel.c of cpucontrol and it seems to work like this: 1. mmap the file 2. analyse the header 3. check the checksum of the payload 4. check for an extended signature table (0f-02-07 does NOT have one) 5. compare cpu signature with header sig and compare cpu flags with header flags. 6. if 5. failed: loop through extended table (if one had been found) and check if sig and flags match. 7. if during 5. or 6. something was found, update cpu However, I've put some debug printfs into intel.c and got the impression that it just checks the first part of file 0f-02-07. This seems logical as the first part of 0f-02-07 is just the same as m02f2738.fw. So there is no extended signature table and the concatenated m04f2737.fw and m08f2739.fw simply get ignored. Maybe on linux they repeat step 2. as long as the file has more data after the payload of the (currently examined) header -- just until EOF. Unfortunatley, I have no cpu where one of these files are needed so I can't test it (and all my assumptions are completely wrong ;-)).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180118180840.GA41197>