Re: [Xen-devel] [PATCH v7 09/10] microcode: remove microcode_update_lock

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.06.19 at 18:04, <ashok.raj@xxxxxxxxx> wrote:
> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
>> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>> >
>> >> @@ -307,8 +303,7 @@ static int apply_microcode(const struct 
>> >> microcode_patch 
> *patch)
>> >>  
>> >>      mc_intel = patch->mc_intel;
>> >>  
>> >> -    /* serialize access to the physical write to MSR 0x79 */
>> >> -    spin_lock_irqsave(&microcode_update_lock, flags);
>> >> +    BUG_ON(local_irq_is_enabled());
>> >>  
>> >>      /*
>> >>       * Writeback and invalidate caches before updating microcode to avoid
>> >
>> >Thinking about it - what happens if we hit an NMI or #MC here?
>> >watchdog_disable(), a call to which you add in an earlier patch,
>> >doesn't really suppress the generation of NMIs, it only tells the
>> >handler not to look at the accumulated statistics.
>> 
>> I think they should be suppressed. Ashok, could you confirm it?
> 
> I think the only sources would be the watchdog as you pointed out
> which we already touch to keep it from expiring. The perf counters
> i'm not an expert in, but i'll check. When we are in stop_machine() type
> flow, its not clear if any of those would fire. (I might be wrong, but let
> me check).

Well, without disarming the watchdog NMI at the LAPIC / IO-APIC,
how would it _not_ potentially fire?

> #MC shouldn't fire once you entered the rendezvous, if it does its usually
> fatal like a 3strike or something. Machine is going down at that time
> so nothing we could do to handle.

Right - as long as we assume that #MC would be fatal anyway,
there's no point in thinking about ways to suppress it. I guess
it is fatal (almost) always right now, but I don't think it ought to
be. It's just that no-one has the time and environment to make
it actually behave better.

Jan



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