[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 4/4] x86/microcode: Disable microcode update handler if DIS_MCU_UPDATE is set



On Wed, Jul 05, 2023 at 12:51:47PM +0200, Jan Beulich wrote:
> > --- a/xen/arch/x86/cpu/microcode/intel.c
> > +++ b/xen/arch/x86/cpu/microcode/intel.c
> > @@ -385,6 +385,19 @@ static struct microcode_patch *cf_check 
> > cpu_request_microcode(
> >      return patch;
> >  }
> >  
> > +bool __init intel_can_load_microcode(void)
> > +{
> > +    uint64_t mcu_ctrl;
> > +
> > +    if ( !cpu_has_mcu_ctrl )
> > +        return true;
> > +
> > +    rdmsrl(MSR_MCU_CONTROL, mcu_ctrl);
> 
> While one would hope that feature bit and MSR access working come in
> matched pairs, I still wonder whether - just to be on the safe side -
> the caller wouldn't better avoid calling here when rev == ~0 (and
> hence we won't try to load ucode anyway). I would envision can_load's
> initializer to become this_cpu(cpu_sig).rev != ~0, with other logic
> adjusted as necessary in early_microcode_init().
> 
> Jan
We only know about the ucode revision after the collect_cpu_info() call,
and we can only make that call after the vendor-specific section that sets
the function pointers up (and calls intel_can_load_microcode()).

One could imagine turning can_load into a function pointer so that its
execution is deferred until after the revision check (and skipped
altogether if `rev==~0`).

Alejandro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.