Re: [PATCH 1/4] genirq: Provide basic NMI management for interrupt lines

[Thomas Gleixner]

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.

Thanks,

	tglx