Re: [Xen-devel] [PATCH v5 8/8] microcode: update microcode on cores in parallel

[Roger Pau Monné]

On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 08:06, <chao....@intel.com> wrote:
> > @@ -314,9 +310,7 @@ static int apply_microcode(unsigned int cpu)
> >  
> >      mc_intel = patch->data;
> >      BUG_ON(!mc_intel);
> > -
> > -    /* serialize access to the physical write to MSR 0x79 */
> > -    spin_lock_irqsave(&microcode_update_lock, flags);
> > +    BUG_ON(local_irq_is_enabled());
> >  
> >      /* write microcode via MSR 0x79 */
> >      wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc_intel->bits);
> > @@ -329,7 +323,6 @@ static int apply_microcode(unsigned int cpu)
> >      rdmsrl(MSR_IA32_UCODE_REV, msr_content);
> >      val[1] = (uint32_t)(msr_content >> 32);
> >  
> > -    spin_unlock_irqrestore(&microcode_update_lock, flags);
> >      if ( val[1] != mc_intel->hdr.rev )
> >      {
> >          printk(KERN_ERR "microcode: CPU%d update from revision "
> 
> Am I understanding right that you now rely on upper layers in the
> call tree to avoid calling into here in parallel for two hyperthreads
> of the same core? I can't see how you avoid this situation during
> AP bringup, for example. Did I overlook anything in this regard?

IIRC microcode update is done in the serialized part of AP bringup,
before the call to smp_callin, which guarantees serialization.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel