On 28/03/2023 5:01 pm, Jan Beulich wrote: > On 28.03.2023 17:12, Andrew Cooper wrote: >> On 28/03/2023 3:19 pm, Jan Beulich wrote: >>> On 27.03.2023 21:41, Andrew Cooper wrote: >>>> Right now, the boot flow depends on the second pass over >>>> bootstrap_map()/find_cpio_data() altering ucode_blob.data to use the >>>> directmap >>>> alias of the CPIO module, where previously it caches the early boostrap >>>> mapping. >>>> >>>> If the scan is successful, it will be successful the second time too, but >>>> there's no point repeating the work. Cache the module index, offset and >>>> size >>>> to short circuit things the second time around. >>> If the scan failed, it will fail the 2nd time too. Maybe deal with >>> this case as well, e.g. by clearing ucode_scan at the end of >>> microcode_scan_module() when nothing was found? >> See patch 5. It can only become true then because of how the callers >> are arranged. > Right, I've meanwhile seen you do it there. That's fine. Yet I think it > could also be done earlier (and if I'm not mistaken also ahead of all > of the rearrangements you do).
Prior to patch 5, calls into scan are guarded with "if ( ucode_scan )" as well as there being an "if ( !ucode_scan )" check. Clobbering ucode_scan prior to patch 5 breaks the second pass to cache the ucode we loaded on the BSP. ~Andrew
