[lkml]   [2018]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/4] genirq: Provide basic NMI management for interrupt lines
On Thu, 2 Aug 2018, Ricardo Neri wrote:
> On Thu, Aug 02, 2018 at 11:40:55AM +0200, Thomas Gleixner wrote:
> > Yes, focussing on "sane" architectures (by some definition of sane) where
> > the NMI mode is just changing the delivery restrictions allows to still
> > differentiate from which source the NMI originates.
> Let me assume that one can find a way to reliably identify the source of an
> NMI in x86.

This assumption is fundamentally wrong. It wont't work unless Intel decides
to sanitize the whole exception mechanism. We can discuss that once this
happens, but I assume that this will be after my retirement.

> If we cannot use the proposed request_nmi() as it does not fit
> x86, is it acceptable to bypass the existing irq framework and directly
> program the delivery mode as NMI in the relevant hardware (e.g., a register
> holding the MSI data)? For instance, in my initial attempt to have the HPET
> timer to generate NMIs [1]. I could directly write to the FSB Interrupt
> Route Register. In my view, it makes sense because, as you say, in x86 NMIs
> are handled separately from the normal vector based interrupts.

That HPET thing is a dead horse and won't become more alive by adding magic
to the irq core code.

> I guess this would also imply reserving the relevant hardware so that it
> is not used when calling request_irq().

There is nothing to reserve. Code which needs to deal with NMIs is better
written safe and sound and no, we won't expose NMIs to random device driver
code either.



 \ /
  Last update: 2018-08-03 10:00    [W:0.042 / U:9.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site