Attention is currently required from: Tarun Tuli, Reka Norman, Kapil Porwal, Julius Werner, Arthur Heymans, Lean Sheng Tan.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74873 )
Change subject: cpu/intel/microcode: Implement microcode info caching inside cbmem ......................................................................
Patch Set 4:
(1 comment)
Patchset:
PS3:
I assume this patch is in response to b/242473942? And your time savings aren't really from "searching", they're from bypassing CBFS verification?
If we determined that we actually *want* to bypass CBFS verification, and that it is safe to do so, there are more straight-forward ways to do that (e.g. cbfs_unverified_area_map()). But my understanding from the previous discussion on the bug was that we don't actually want to do that because there could actually be some attack vector here (even if it's e.g. just a rollback attack). In that case, we obviously also can't do something like this.
yes, your understanding is correct that we don't want to bypass the CBFS verification check
also i have noticed ~10ms boot time impact with every new ucode (per cpu stepping) being added into the cpu_microcode_blob.bin
for example: current REX (MTL) added 2 ucode for ES1 and ES2 hence, the timestamp ID 971 was around 20ms. if we drop ES2 support and keep only ES1 then the boot time (timestamp ID 971) is 10ms
Instead of concatenating microcode you could add a cbfs file per cpuid? That would not bypass CBFS verification and result in the same speedup.
isn't the expectation inside find_cbfs_microcode() function is that, there would be one single microcode entry inside CBFS?
Yes. My suggestion implies changing that :-)
Ah, that should be long pole as we would like to get some solution for existing devices where we are not meeting the KPI numbers by 10-15ms 😭