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.

Cheers,

--
Julien Grall

Reply via email to