Re: [Xen-devel] [PATCH 2/2] x86/microcode: Do not upload microcode if CPUs are offline

[Borislav Petkov <bp@xxxxxxxxx>]

On Fri, Apr 13, 2018 at 10:57:46AM -0700, Raj, Ashok wrote:
> > I'm afraid I don't fully agree - not applying an ucode update to the online
> > CPUs because some are offline isn't any better. Plus (while updating)
> > there's always going to be some discrepancy between ucode versions.
> > As long as we apply updates while bringing a CPU online, I think we're fine.

When a core is soft-offlined as we do it, it doesn't mean that it
doesn't execute instructions...

> This is the safest option. Microcode is considered part of the cpu. We don't
> allow cpus with different capabilities in the same system.. yes they might
> work, but not something we allow.

... so yes, we better be safe than having to debug some insane lockups.

> In general we recommend early update. Earliest the best. 
> 
> - BIOS update (difficult to deploy, but some microcodes have to be done
>   this way.)
> - early update from initrd.. almost same as #1, since we apply at earliest
>   chance that's the closest and most recommended method.
> - late update. Before this procedure of stopping all cpus, we did have a 
>   time when some are updated and some werent uptodate yet. This synchronized
>   update is precicely to get as close as possible to updating all of them.

Yap.

> > Also please consider valid cases you make not work anymore, like someone
> > having brought offline all sibling hyperthreads, with each core still having
> > one thread active. In that case an ucode update will implicitly update all
> > offline threads as well.

That's some strange use case which I can't imagine worked, like ever.
Because the microcode engine is shared between the HT threads so no
matter on which of the hyperthreads you update, the same, one and only
engine gets updated.

> Of cource we can tweak this to be much better, there are other ideas, but
> this is an effort to keep this simple, and also address microcode requirements
> post spectre for some processors.  In the grand scheme of things although its
> interesting to allow such updates we think it may not be best practice.
> 
> We want to get this working right first before getting fancy.

Ack.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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