Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback

[Ingo Molnar]

* H. Peter Anvin <hpa@xxxxxxxxx> wrote:

> Ingo Molnar wrote:
>>
>> i'd much rather attack this general problem from this angle:
>>
>>   static inline unsigned char get_nmi_reason(void)
>>   {
>>           return inb(0x61);
>>   }
>>
>> that port 61H read is both arcane (on modern chipsets) and broken on  
>> multiple levels. It's racy and SMP unsafe to begin with, if there's any 
>> mixture of intentional cross-CPU or CPU self-generated NMIs mixed with  
>> chipset generated NMIs.
>>
>> One possible approach would be to get rid of it, and to perhaps 
>> register a low-priority die notifier on systems where we know port 61  
>> reads+writes to be safe and desired. Modern systems will emit MCEs in  
>> most cases anyway, not NMIs.
>>
>
> I believe we should still do it, but as the lowest priority "nothing 
> else claimed this".  It reflects a system error and not all systems 
> will generate #MC instead of NMI for all system errors.
>
> Pretty much what you're saying above.

ok. One potential additional concern i can think of is multi-source 
NMIs: NMIs, when generated by some sort of hardware are edge triggered 
most of the time, so if in the notifier chain a notifier decides "this 
was for me, return now", we will lose an event.

So i think we should iterate through all notifier entries and call them 
(even if all of them indicate that they handled it), and determine 
whether at least one notifier handled something. If nothing handled the 
NMI _then_ do the port 61H logic as a final fall-back thing.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/