Re: [Xen-devel] [PATCH v1 3/4] x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.01.2020 23:30, Eslam Elnikety wrote:
> When using `ucode=scan` and if a matching module is found, the microcode
> payload is maintained in an xmalloc()'d region. This is unnecessary since
> the bootmap would just do. Remove the xmalloc and xfree on the microcode
> module scan path.
> 
> This commit also does away with the restriction on the microcode module
> size limit. The concern that a large microcode module would consume too
> much memory preventing guests launch is misplaced since this is all the
> init path. While having such safeguards is valuable, this should apply
> across the board for all early/late microcode loading. Having it just on
> the `scan` path is confusing.
> 
> Looking forward, we are a bit closer (i.e., one xmalloc down) to pulling
> the early microcode loading of the BSP a bit earlier in the early boot
> process. This commit is the low hanging fruit. There is still a sizable
> amount of work to get there as there are still a handful of xmalloc in
> microcode_{amd,intel}.c.
> 
> First, there are xmallocs on the path of finding a matching microcode
> update. Similar to the commit at hand, searching through the microcode
> blob can be done on the already present buffer with no need to xmalloc
> any further. Even better, do the filtering in microcode.c before
> requesting the microcode update on all CPUs. The latter requires careful
> restructuring and exposing the arch-specific logic for iterating over
> patches and declaring a match.
> 
> Second, there are xmallocs for the microcode cache. Here, we would need
> to ensure that the cache corresponding to the BSP gets xmalloc()'d and
> populated after the fact.
> 
> Signed-off-by: Eslam Elnikety <elnikety@xxxxxxxxxx>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Btw, if you could confirm (also for patch 4) that this is independent
of patches 1 and 2 (it looks like so to me at least), then surely the
two ones could go in independent and ahead of patch 2.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel