On 01.08.2019 12:22, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -78,23 +78,23 @@ struct mpbhdr {
> static DEFINE_SPINLOCK(microcode_update_lock);
>
> /* See comment in start_update() for cases when this routine fails */
> -static int collect_cpu_info(unsigned int cpu, struct cpu_signature *csig)
> +static int collect_cpu_info(struct cpu_signature *csig)
> {
> - struct cpuinfo_x86 *c = &cpu_data[cpu];
> + struct cpuinfo_x86 *c = ¤t_cpu_data;
>
> memset(csig, 0, sizeof(*csig));
>
> if ( (c->x86_vendor != X86_VENDOR_AMD) || (c->x86 < 0x10) )
> {
> printk(KERN_ERR "microcode: CPU%d not a capable AMD processor\n",
> - cpu);
> + smp_processor_id());
> return -EINVAL;
> }
>
> rdmsrl(MSR_AMD_PATCHLEVEL, csig->rev);
>
> pr_debug("microcode: CPU%d collect_cpu_info: patch_id=%#x\n",
> - cpu, csig->rev);
> + smp_processor_id(), csig->rev);
>
> return 0;
> }
Argh - I'd been wrong saying "The only other use of "cpu" is in a
pr_debug()" in a reply to v7. I had managed to overlook the use in
the printk(). This suggests that the earlier solution was better,
as now we have at least two smp_processor_id() in the function, in
a debug build three of them. I'm sorry.
Reviewed-by: Jan Beulich <jbeul...@suse.com>
preferably with the change above moved back to its v7 shape, but
given this was my mistake I won't insist. If there was no need for
v9, then this could also be done while committing.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
