lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] x86, NMI, Treat unknown NMI as hardware error
On 05/16/2011 05:09 AM, Huang Ying wrote:
...
>>
>> I'm personally fine even if it's enabled by default, only worried to have
>> an option to disable hwerr from boot line.
>
> The white list mechanism is not sufficient? Spurious unknown NMI can
> occur on white list machines? People don't want to protect their data?
>

I suppose no, it's not sufficient considering how many cpu errata already
out in general. And I see no guarantee that unknown NMIs never triggers on
white list machines and I know that you know that as well ;)

>>> And, I am not a big fan of notifiers, that makes code hard to be
>>> understood. If you have concerns about the size of traps.c, we can
>>> move all NMI logic to a new file.
>>
>> Ying, the concern is rather related to the code scheme in general. Since
>> we have notifiers I think the better way to be consistent here and use
>> hwerr notifier too. But it's IMHO ;)
>
> As for go notifiers or not. IMHO, a rule can be:
>
> - If it is something like a driver, than it should go notifier
> - If it is architectural/PC defacto standard, it can sit outside of notifier.
>
> I think that seeing unknown NMI as hardware error should be part of PC
> defacto standard. Do you think so?

Ying, movin the handler into notifier is my IMHO, this would release nmi handler
from details since with time more and more "standarts" would appear. If Don, Ingo
and x86-team is fine with your approach -- of course I'm pretty fine too ;)

>
> Best Regards,
> Huang Ying

/me Just found Don has some more concerns

--
Cyrill


\
 
 \ /
  Last update: 2011-05-16 21:47    [W:0.073 / U:111.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site