Re: [PATCH v2 3/3] x86/ucode: load microcode earlier on boot CPU

[Julien Grall <julien@xxxxxxx>]

On 19/12/2022 17:33, Andrew Cooper wrote:
> 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.
Thanks for the clarification!

Cheers,

--
Julien Grall