On 19/12/2022 4:57 pm, Julien Grall wrote: > Hi Sergey, > > On 19/12/2022 14:45, Sergey Dyasli wrote: >> Call early_microcode_init() straight after multiboot modules become >> accessible. Modify it to load the ucode directly from the blob bypassing >> populating microcode_cache because xmalloc is still not available at >> that point during Xen boot. >> >> Introduce early_microcode_init_cache() for populating microcode_cache. >> It needs to rescan the modules in order to find the new virtual address >> of the ucode blob because it changes during the boot process, e.g. >> from 0x00000000010802fc to 0xffff83204dac52fc. >> >> While at it, drop alternative_vcall() from early_microcode_init() since >> it's not useful in an __init fuction. > > Can you explain in the commit message why you need to load the > microcode early? E.g. is it a nice feature to have or a real issue? > > If the latter, then I think we will need to consider the patches for > backport.
Microcode loading should be as early as possible. Linux does it even before setting up the console (which is a bit too early IMO). Xen currently loads microcode half way through BSP boot, because there's a inappropriate dependency on needing xmalloc(). This is what Sergey is addressing with this series. I'm working on addressing the TODO in the penultimate hunk of this patch (resolving some major abuse with with the multiboot module structures), which will let us load microcode even earlier. A consequence of this (relatively) late loading is that we've got a tangle of feature enumeration logic where cpu_has_* doesn't fully work before ucode load, and we've got a lot of ad-hoc logic which is fragile. So no - there's not a specific bug driving this, but a lot of cleanup that I've been wanting to do since before speculation came along. ~Andrew
