Re: [PATCH 01/13] x86/microcode/intel: Print old and new rev after early microcode update

[Ashok Raj]

On Wed, Oct 19, 2022 at 12:12:00PM +0200, Borislav Petkov wrote:
> On Fri, Oct 14, 2022 at 01:09:01PM -0700, Ashok Raj wrote:
> > @@ -435,10 +435,10 @@ static bool load_builtin_intel_microcode(struct cpio_data *cp)
> >   * Print ucode update info.
> >   */
> >  static void
> > -print_ucode_info(struct ucode_cpu_info *uci, unsigned int date)
> > +print_ucode_info(u32 old_rev, struct ucode_cpu_info *uci, unsigned int date)
> >  {
> > -	pr_info_once("microcode updated early to revision 0x%x, date = %04x-%02x-%02x\n",
> > -		     uci->cpu_sig.rev,
> > +	pr_info_once("microcode updated early from 0x%x to revision 0x%x, date = %04x-%02x-%02x\n",
> 
> That already has the "microcode: " prefix from pr_fmt so make that
> 
> 		     "early update: 0x%x -> 0x%x, date = %04x-%02x-%02x\n"
> 
> and fix the late update message too, pls, to look the same without the
> "early" in there.

Good point, Fixed this.

> 
> > @@ -479,13 +481,15 @@ static void print_ucode(struct ucode_cpu_info *uci)
> >  
> >  	delay_ucode_info_p = (int *)__pa_nodebug(&delay_ucode_info);
> >  	current_mc_date_p = (int *)__pa_nodebug(&current_mc_date);
> > +	old_rev_p = (u32 *)__pa_nodebug(&early_old_rev);
> 
> No, you should add a
> 
> 	u32 prev_rev;
> 
> to struct ucode_cpu_info, save it there and access it where needed.

This seems like some 32bit restriction that we can't use printk early? I
wasn't sure, so I just followed what was done prior.

Today it seems we are doing the print just for BSP, not for all CPUs. Just
like what we do after update. Do you want to save this for all CPUs in
ucode_cpu_info[] for the previous revision?

Also its weird that cpu/common.c calls show_ucode_info_early(), but only
defined in cpu/microcode/intel.c. There is none in the AMD side.

Do you think we could have a generic function in cpu/microcore/core.c, that
calls vendor specific calls like the other early functions?
> 
> Then I can do the same prev -> next revision dumping on the AMD side.
> 

Cheers,
Ashok