Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI irq domain

[Jason Gunthorpe]

On Thu, Jul 23, 2020 at 09:51:52AM +0100, Marc Zyngier wrote:

> > IIRC on Intel/AMD at least once a MSI is launched it is not maskable.
> 
> Really? So you can't shut a device with a screaming interrupt,
> for example, should it become otherwise unresponsive?

Well, it used to be like that in the APICv1 days. I suppose modern
interrupt remapping probably changes things.

> > So the model for MSI is always "mask at source". The closest mapping
> > to the Linux IRQ model is to say the end device has a irqchip that
> > encapsulates the ability of the device to generate the MSI in the
> > first place.
> 
> This is an x86'ism, I'm afraid. Systems I deal with can mask any
> interrupt at the interrupt controller level, MSI or not.

Sure. However it feels like a bad practice to leave the source
unmasked and potentially continuing to generate messages if the
intention was to disable the IRQ that was assigned to it - even if the
messages do not result in CPU interrupts they will still consume
system resources.

> > I suppose the motivation to make it explicit is related to vfio using
> > the generic mask/unmask functionality?
> > 
> > Explicit seems better, IMHO.
> 
> If masking at the source is the only way to shut the device up,
> and assuming that the device provides the expected semantics
> (a MSI raised by the device while the interrupt is masked
> isn't lost and gets sent when unmasked), that's fair enough.
> It's just ugly.

It makes sense that the masking should follow the same semantics for
PCI MSI masking.

Jason