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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.04.18 at 19:57, <ashok.raj@xxxxxxxxx> wrote:
> On Fri, Apr 13, 2018 at 09:57:25AM -0600, Jan Beulich wrote:
>> >>> On 30.03.18 at 08:59, <chao.gao@xxxxxxxxx> wrote:
>> > This patch is to backport the patch below from linux kernel.
>> > 
>> >     commit 30ec26da9967d0d785abc24073129a34c3211777
>> >     Author: Ashok Raj <ashok.raj@xxxxxxxxx>
>> >     Date:   Wed Feb 28 11:28:43 2018 +0100
>> > 
>> >         x86/microcode: Do not upload microcode if CPUs are offline
>> > 
>> >         Avoid loading microcode if any of the CPUs are offline, and issue a
>> >         warning. Having different microcode revisions on the system at any 
>> > time
>> >         is outright dangerous.
>> 
>> 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.
> 
> 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. 

Please compare with the boot time CPU bringup cases: Just like when onlining
a CPU at run time, the new microcode is put in place early during bringing up
the CPU. I don't see the difference in risk, yet from what you say we should
disallow boot time applying ucode to the BSP (much earlier than the APs) as
well.

> 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.
>> 
>> 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.
> 
> 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.

Simplicity and correctness are very worthwhile goals, but please without
regressing valid scenarios.

Jan



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