Re: [PATCH 05/11] x86/ucode/amd: Overhaul the equivalent cpu table handling completely

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.03.2020 12:05, Andrew Cooper wrote:
> We currently copy the entire equivalency table, and the single correct
> microcode.  This is not safe to heterogeneous scenarios, and as Xen doesn't
> support such situations to being with, can be used to simplify things further.

s/being/begin/ ?

> The CPUID.1.EAX => processor_rev_id mapping is fixed for an individual part.
> We can cache the single appropriate entry on first discovery, and forgo
> duplicating the entire table.
> 
> Alter install_equiv_cpu_table() to be scan_equiv_cpu_table() which is
> responsible for checking the equivalency table and caching appropriate
> details.  It now has a check for finding a different mapping (which indicates
> that one of the tables we've seen is definitely wrong).
> 
> A return value of -ESRCH is now used to signify "everything fine, but nothing
> applicable for the current CPU", which is used to select the
> container_fast_forward() path.
> 
> Drop the printk(), as each applicable error path in scan_equiv_cpu_table()
> already prints diagnostics.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>