|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 3/4] x86: Read MSR_ARCH_CAPS immediately after early_microcode_init()
On Wed, Jul 05, 2023 at 12:43:27PM +0200, Jan Beulich wrote:
> On 29.06.2023 17:26, Alejandro Vallejo wrote:
> > @@ -324,9 +324,10 @@ void __init early_cpu_init(void)
> > case X86_VENDOR_SHANGHAI: this_cpu = &shanghai_cpu_dev; break;
> > case X86_VENDOR_HYGON: this_cpu = &hygon_cpu_dev; break;
> > default:
> > - printk(XENLOG_ERR
> > - "Unrecognised or unsupported CPU vendor '%.12s'\n",
> > - c->x86_vendor_id);
> > + if (verbose)
> > + printk(XENLOG_ERR
> > + "Unrecognised or unsupported CPU vendor
> > '%.12s'\n",
> > + c->x86_vendor_id);
>
> Just as a remark:
>
> if (!verbose)
> break;
>
> would have been less of a delta and keeping all lines within the 80
> chars limit.
Very true, that looks nicer.
> > @@ -340,10 +341,11 @@ void __init early_cpu_init(void)
> > c->x86_capability[FEATURESET_1d] = edx;
> > c->x86_capability[FEATURESET_1c] = ecx;
> >
> > - printk(XENLOG_INFO
> > - "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u
> > (raw %08x)\n",
> > - x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
> > - c->x86_model, c->x86_model, c->x86_mask, eax);
> > + if (verbose)
> > + printk(XENLOG_INFO
> > + "CPU Vendor: %s, Family %u (%#x), Model %u (%#x),
> > Stepping %u (raw %08x)\n",
> > + x86_cpuid_vendor_to_str(boot_cpu_data->x86_vendor),
> > c->x86, c->x86,
> > + c->x86_model, c->x86_model, c->x86_mask, eax);
>
> Since rearrangement to limit line length isn't really possible here,
> the last two lines need re-flowing to stay within limits.
I assumed they could could share the length of the printk string. I don't
mind either way.
>
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -886,5 +886,11 @@ int __init early_microcode_init(unsigned long
> > *module_map,
> > if ( ucode_mod.mod_end || ucode_blob.size )
> > rc = early_microcode_update_cpu();
> >
> > + /*
> > + * MSR_ARCH_CAPS may have appeared after the microcode update. Reload
> > + * boot_cpu_data if so because they are needed in tsx_init().
> > + */
> > + early_cpu_init(false);
>
> I think the comment would better talk of ARCH_CAPS as an example of what
> may newly appear with a ucode update.
I just started writing a paragraph stating that it's unlikely anything else
will just appear, but thinking it through you're definitely right. A new
MSR_NEW_SPEC_MITIGATIONS might very well appear.
Something along this lines would be better?
```
* Microcode updates may change CPUID or MSRs. We need to reload
* the early subset boot_cpu_data before continuing. Notably tsx_init()
* needs an up to date MSR_ARCH_CAPS.
```
>
> With at least the middle item taken care of (which I'd be happy to
> do while committing)
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Jan
Thanks. I'm happy with all 3 changes being done on commit.
Alejandro
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |