-
Notifications
You must be signed in to change notification settings - Fork 77
releasenote.md: cleanup and fixes (on top of microcode-20250211) #95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
microcode-20231114 release has removed the baffling usage of U+0080; however, unfortunately, it also has misaligned the "New Platforms" table of the microcode-20230808 release and "Updated Platforms" table of the microcode-20230214 release; fix that. Fixes: ece0d29 "microcode-20231114 Release" Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Starting with microcode-20220809, the first-level "Release Notes" header is duplicated for unknown reason; remove it, as it does not make sense to have it multiple times in the middle of the document, consider the fact that first-level header is usually reserved for the document name (and it seems that it indeed bears that role). * releasenote.md: Remove all "Release Notes" headers after the first one. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
…cally microcode-20230214 seemingly (but not fully; the "New Platforms" section still have used the old sorting order) have switched the entries order from sorting on the FF-MM-SS/PI field to sorting on the Codename field (which is arguably significantly less useful and much more confusing, especially in cases of CPUIDs spanning several code names, such as 06-8e-0[9ac]). However, it is impossible to devise the sorting order of the entries in the microcode-20230808 changelog table, which makes it even more difficult to navigate, so this patch just changes it to the lastly used one. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
microcode-20230214, microcode-20230512, and microcode-20230512-rev2 release notes state that the platform mask for CPUIDs with FF-MM-SS 06-ba-02 and 06-ba-03 is 0x07, but it is, in fact, 0xc0: $ iucode_tool -L microcode-20230{214,512,512-rev2}/intel-ucode/06-ba-0[23] microcode bundle 1: microcode-20230214/intel-ucode/06-ba-02 001/001: sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e sig 0x000b06a3, pf_mask 0xc0, 2022-12-08, rev 0x410e microcode bundle 2: microcode-20230214/intel-ucode/06-ba-03 002/001: sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e sig 0x000b06a3, pf_mask 0xc0, 2022-12-08, rev 0x410e microcode bundle 3: microcode-20230512/intel-ucode/06-ba-02 003/001: sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112 sig 0x000b06a3, pf_mask 0xc0, 2023-02-22, rev 0x4112 microcode bundle 4: microcode-20230512/intel-ucode/06-ba-03 004/001: sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112 sig 0x000b06a3, pf_mask 0xc0, 2023-02-22, rev 0x4112 microcode bundle 5: microcode-20230512-rev2/intel-ucode/06-ba-02 005/001: sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112 sig 0x000b06a3, pf_mask 0xc0, 2023-02-22, rev 0x4112 microcode bundle 6: microcode-20230512-rev2/intel-ucode/06-ba-03 006/001: sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112, size 212992 sig 0x000b06a2, pf_mask 0xc0, 2023-02-22, rev 0x4112 sig 0x000b06a3, pf_mask 0xc0, 2023-02-22, rev 0x4112 Also, fix incorrect RPL-U stepping in the microcode-20230214 table. * releasenote.md (microcode-20230214, microcode-20230512, microcode-20230512-rev2) <RPL-H 6+8, RPL-P 6+8>: Change the F-M-S field from 06-ba-02/07 to 06-ba-02/c0. (microcode-20230214) <RPL-U 2+8>: Change the F-M-S field from 06-ba-02/07 to 06-ba-03/c0. (microcode-20230512, microcode-20230512-rev2) <RPL-U 2+8>: Change the F-M-S field from 06-ba-03/07 to 06-ba-03/c0. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
microcode-20221108, microcode-20230214, microcode-20230512, and microcode-20230512-rev2 release notes (incorrectly) state RPL-S (06-b7-01/32) stepping as S0, while microcode-20230808 release notes state it as B0, and [1] confirms the correctness of the latter. [1] "13th Generation Intel Core Processors. Datasheet, Volume 1 of 2" Rev. 005, February 2023, section 15.0 "CPU And Device IDs" https://cdrdv2-public.intel.com/743844/743844-005.pdf * releasenote.md (microcode-20221108, microcode-20230214, microcode-20230512, microcode-20230512-rev2) <RPL-S>: Change the stepping field value from "S0" to "B0". Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
microcode-20230808 release notes for CPUIDs 06-ba-02/e0 (RPL-H/P/PX 6+8), 06-ba-03/e0 (RPL-U 2+8), and 06-be-00/11 (ADL-N) are peculiar in a way that these CPUIDs have their PF mask values changed (from 06-ba-02/c0, 06-ba-03/c0, and 06-be-00/01, respectively). Since 06-ba-02/e0 and 06-be-00/11 are listed both in "New Platforms" and "Updated Platforms" sections (which makes some sense, as it is both addition of the platform 0x10 and update for the rest of the platforms), it is natural to assume that this is done this way on purpose, and that 06-ba-03/e0 of these three is accidentally missing from the "New Platforms" section. * releasenote.md (microcode-20230808) <New Platforms>: Add 06-ba-03/e0 (RPL-U 2+8) entry. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
CFL-S stepping P0 (06-9e-0c/22) is already listed as "CFL-H/S" and it has not been listed in the notes to the previous releases separately. * releasenote.md (microcode-20230808) <CFL-S P0>: Remove. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
…ries The values provided are from the microcode-20230214 release, even though they have been updated in microcode-20230512. Curiously, only one entry of two with CPUID of 06-55-04/b7 has manifested this mistake. * releasenote.md (microcode-20230808) <AML-Y22 H0>: Change the "Old Ver" field from 000000f0 to 000000f2. (microcode-20230808) <SKX-SP H0/M0/U0>: Change the "Old Ver" field from 02006e05 to 02006f05. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
…6-ba-03/e0 As has been mentioned already in commit "releasenote.md: add missing 06-ba-03/e0 to the new microcode section", platforms with CPUIDs 06-be-00, 06-ba-02, and 06-ba-03 have their platform mask changed and thusly listed in both "New Platforms" and "Updated Platforms" sections of microcode-20230808 release notes. It is, however, puzzling to have the "Old Ver" field of these entries empty in the "Updated Platforms" section, so it seemingly make sense to populate it with the previous microcode versions for the existing platforms. * releasenote.md (microcode-20230808) <Updated Platforms>: Provide 00000010 as the "Old Ver" field value for ADL-N A0 (06-be-00/11, nee 06-be-00/01); provide 00004112 as the "Old Ver" field value for RPL-H/P/PX 6+8 J0 (06-ba-02/e0, nee 06-ba-02/c0) and RPL-U 2+8 Q0 (06-ba-03/e0, nee 06-ba-03/c0). Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Release notes for microcode-20250211 and microcode-20220809 releases contain trailing white space that seemingly serves no particular purpose; remove it. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
…microcode For some reason, information about updates and removals of 06-8f-04 (SPR-SP E0), 06-8f-05 (SPR-SP E2), and 06-8f-06 (SPR-SP E3) microcode files is missing from microcode-20240312, microcode-20241112, and microcode-20250211 release notes. Document those properly. * releasenote.md (microcode-20250211): Mention removal of 06-8f-05 and 06-8f-06 microcode files. (microcode-20241112): Mention update of 06-8f-05 microcode from revision 0x2b0005c0 up to 0x2b000603. (microcode-20240312): Mention removal of 06-8f-04 microcode file. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
This microcode file was first appeared as part of microcode-20240312, was present in the following releases up to microcode-20241112, and was removed in microcode-20250211. While [1] mentions that there are no products in production that would use that microcode, it does not warrant creation of discrepancy between the release notes and the actually shipped contents; moreover, presence of 60BA8 CPUID in [2] hints at its possible availability, after all. NB: This CPUID can still be updated with the latest 06-ba-0* microcode even despite removal of the microcode file, as it shares the microcode data with 06-ba-02 and 06-ba-03 microcode files, that still contain it in the extended signature: % iucode_tool -L microcode-20250211/intel-ucode/06-ba-02 microcode bundle 1: microcode-20250211/intel-ucode/06-ba-02 001/001: sig 0x000b06a2, pf_mask 0xe0, 2024-07-31, rev 0x4124, size 220160 sig 0x000b06a2, pf_mask 0xe0, 2024-07-31, rev 0x4124 sig 0x000b06a3, pf_mask 0xe0, 2024-07-31, rev 0x4124 sig 0x000b06a8, pf_mask 0xe0, 2024-07-31, rev 0x4124 [1] intel#83 (comment) [2] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01139.html * releasenote.md (microcode-20240312): Mention addition of the microcode at revision 0x4121. (microcode-20240910): Mention an update to revision 0x4122. (microcode-20241112) Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
* releasenote.md (microcode-20240531): Add missing spaces in the 06-cf-01 and 06-cf-02 (EMR-SP) entries. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Having an empty table (with an additional empty line, compared to non-empty ones) is really inconsistent. * releasenote.md (microcode-20241112, microcode-20241029, microcode-20240813, microcode-20240531, microcode-20240514, microcode-20231114): Replace empty tables in the "New Platforms" sub-section with "None". Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
…e notes There is little reason to keep those botched. * releasenote.md (microcode-20230512): Add old revisions for 06-8e-09/10 (AML-Y22), 06-8e-09/c0 (KBL-U/Y), 06-55-04/b7 (SKX-D, SKX-SP), and 06-8e-0b/d0 (WHL-U) CPUIDs. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
The empty lines are pretty inconsistent in the latest releases. Apply the following rules uniformely throughout the release notes: * two empty lines before the each release section (except the first one); * a single empty line between sub-sections within each section; * a single empty line between security and functional issue lists in the "Purpose" sub-section. Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the first release that can be applied to the new processors added by the changed pf_mask.
IMHO, either the old revision field should be blank if the rest of the line only applies to the new processor (that got added to the pf_mask), or the old revision field should have a (*) or footnote, stating that it is the first version for pf 0x when the line is also for processors previously supported by the pf_mask.
THIS COMMENT APPLIES TO PATCH "releasenote.md: fix old revisions for 06-be-00/11, 06-ba-02/e0, and 06-ba-03/e0", ONLY. Ugh, this is the last time I bother reviewing anything using github comments. I apologize for the many edits on this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, as mentioned in the commit message, it is assumed that the part "the old revision field should be blank if the rest of the line only applies to the new processor" is covered by the entries in the "New Platforms" sub-section, but you are right that it is impossible to figure out what was the change in the pf_mask; I was wary of adding any asterisks inside the table, as I'm not sure whether the release notes are supposed to be machine-readable (I only use them for diffing with the generated release notes), but such a concern is probably superfluous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about this amendment?
diff --git i/releasenote.md w/releasenote.md
index c407920..d4b73ac 100644
--- i/releasenote.md
+++ w/releasenote.md
@@ -495,7 +495,7 @@ None
| ADL | C0 | 06-bf-05/07 | 0000002c | 0000002e | Core Gen12
| ADL | L0 | 06-9a-03/80 | 0000042a | 0000042c | Core Gen12
| ADL | L0 | 06-9a-04/80 | 0000042a | 0000042c | Core Gen12
-| ADL-N | A0 | 06-be-00/11 | 00000010 | 00000011 | Core i3-N305/N300, N50/N97/N100/N200, Atom x7211E/x7213E/x7425E
+| ADL-N (1) | A0 | 06-be-00/11 | 00000010 | 00000011 | Core i3-N305/N300, N50/N97/N100/N200, Atom x7211E/x7213E/x7425E
| AML-Y22 | H0 | 06-8e-09/10 | 000000f2 | 000000f4 | Core Gen8 Mobile
| AML-Y42 | V0 | 06-8e-0c/94 | 000000f6 | 000000f8 | Core Gen10 Mobile
| CFL-H | R0 | 06-9e-0d/22 | 000000f8 | 000000fa | Core Gen9 Mobile
@@ -520,9 +520,9 @@ None
| KBL-U23e | J1 | 06-8e-09/c0 | 000000f2 | 000000f4 | Core Gen7 Mobile
| KBL-U/Y | H0 | 06-8e-09/c0 | 000000f2 | 000000f4 | Core Gen7 Mobile
| RKL-S | B0 | 06-a7-01/02 | 00000058 | 00000059 | Core Gen11
-| RPL-H/P/PX 6+8 | J0 | 06-ba-02/e0 | 00004112 | 00004119 | Core Gen13
+| RPL-H/P 6+8 (2)| J0 | 06-ba-02/e0 | 00004112 | 00004119 | Core Gen13
| RPL-S | B0 | 06-b7-01/32 | 00000113 | 00000119 | Core Gen13
-| RPL-U 2+8 | Q0 | 06-ba-03/e0 | 00004112 | 00004119 | Core Gen13
+| RPL-U 2+8 (2) | Q0 | 06-ba-03/e0 | 00004112 | 00004119 | Core Gen13
| SKX-D | H0 | 06-55-04/b7 | 02006f05 | 02007006 | Xeon D-21xx
| SKX-SP | B1 | 06-55-03/97 | 01000171 | 01000181 | Xeon Scalable
| SKX-SP | H0/M0/U0 | 06-55-04/b7 | 02006f05 | 02007006 | Xeon Scalable
@@ -538,6 +538,8 @@ None
| WHL-U | V0 | 06-8e-0c/94 | 000000f6 | 000000f8 | Core Gen8 Mobile
| WHL-U | W0 | 06-8e-0b/d0 | 000000f2 | 000000f4 | Core Gen8 Mobile
+(1) The previous version of the microcode had the platform mask value of 0x01.
+(2) Previous versions of the microcode had the platform mask value of 0xc0.
## [microcode-20230512-rev2](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230512-rev2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR supersedes #71, as it is rebased on top of microcode-20250211 and includes some new cleanups and fixes for various inaccuracies in the recent release notes, including the following: