[V2,06/40] PCI/MSI: Provide static key for parent mask/unmask

  Most ARM(64) PCI/MSI domains mask and unmask in the parent domain after or
before the PCI mask/unmask operation takes place. So there are more than a
dozen of the same wrapper implementation all over the place.

Don't make the same mistake with the new per device PCI/MSI domains and
provide a static key which lets the domain implementation enable this
sequence in the PCI/MSI code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/msi/irqdomain.c |   30 ++++++++++++++++++++++++++++++
 include/linux/msi.h         |    2 ++
 2 files changed, 32 insertions(+)
  

On Mon, 21 Nov 2022 14:39:36 +0000,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> Most ARM(64) PCI/MSI domains mask and unmask in the parent domain after or
> before the PCI mask/unmask operation takes place. So there are more than a
> dozen of the same wrapper implementation all over the place.
> 
> Don't make the same mistake with the new per device PCI/MSI domains and
> provide a static key which lets the domain implementation enable this
> sequence in the PCI/MSI code.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> ---
>  drivers/pci/msi/irqdomain.c |   30 ++++++++++++++++++++++++++++++
>  include/linux/msi.h         |    2 ++
>  2 files changed, 32 insertions(+)
> 
> --- a/drivers/pci/msi/irqdomain.c
> +++ b/drivers/pci/msi/irqdomain.c
> @@ -148,17 +148,45 @@ static void pci_device_domain_set_desc(m
>  	arg->hwirq = desc->msi_index;
>  }
>  
> +static DEFINE_STATIC_KEY_FALSE(pci_msi_mask_unmask_parent);
> +
> +/**
> + * pci_device_msi_mask_unmask_parent_enable - Enable propagation of mask/unmask
> + *					      to the parent interrupt chip
> + *
> + * For MSI parent interrupt domains which want to mask at the parent interrupt
> + * chip too.
> + */
> +void pci_device_msi_mask_unmask_parent_enable(void)
> +{
> +	static_branch_enable(&pci_msi_mask_unmask_parent);
> +}
> +
> +static __always_inline void cond_mask_parent(struct irq_data *data)
> +{
> +	if (static_branch_unlikely(&pci_msi_mask_unmask_parent))
> +		irq_chip_mask_parent(data);
> +}
> +
> +static __always_inline void cond_unmask_parent(struct irq_data *data)
> +{
> +	if (static_branch_unlikely(&pci_msi_mask_unmask_parent))
> +		irq_chip_unmask_parent(data);
> +}
> +
>  static void pci_mask_msi(struct irq_data *data)
>  {
>  	struct msi_desc *desc = irq_data_get_msi_desc(data);
>  
>  	pci_msi_mask(desc, BIT(data->irq - desc->irq));
> +	cond_mask_parent(data);

I find this a bit odd. If anything, I'd rather drop the masking at the
PCI level and keep it local to the interrupt controller, because this
is likely to be more universal than the equivalent PCI operation
(think multi-MSI, for example, which cannot masks individual MSIs).

Another thing is that the static key is a global state. Nothing says
that masking one way or the other is a universal thing, specially when
you have multiple interrupt controllers dealing with MSIs in different
ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
at the same time for different PCI RC. OK, they happen to deal with
MSIs in the same way, but you hopefully get my point.

Thanks,

	M.
  

On Thu, Nov 24 2022 at 13:04, Marc Zyngier wrote:
> On Mon, 21 Nov 2022 14:39:36 +0000,
>>  static void pci_mask_msi(struct irq_data *data)
>>  {
>>  	struct msi_desc *desc = irq_data_get_msi_desc(data);
>>  
>>  	pci_msi_mask(desc, BIT(data->irq - desc->irq));
>> +	cond_mask_parent(data);
>
> I find this a bit odd. If anything, I'd rather drop the masking at the
> PCI level and keep it local to the interrupt controller, because this
> is likely to be more universal than the equivalent PCI operation
> (think multi-MSI, for example, which cannot masks individual MSIs).
>
> Another thing is that the static key is a global state. Nothing says
> that masking one way or the other is a universal thing, specially when
> you have multiple interrupt controllers dealing with MSIs in different
> ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
> at the same time for different PCI RC. OK, they happen to deal with
> MSIs in the same way, but you hopefully get my point.

I'm fine with dropping that. I did this because basically all of the
various ARM PCI/MSI domain implementation have a copy of the same
functions. Some of them have pointlessly the wrong order because copy &
pasta is so wonderful....

So the alternative solution is to provide _ONE_ set of correct callbacks
and let the domain initialization code override the irq chip callbacks
of the default PCI/MSI template.

Thanks,

        tglx
  

On Thu, 24 Nov 2022 13:17:00 +0000,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Thu, Nov 24 2022 at 13:04, Marc Zyngier wrote:
> > On Mon, 21 Nov 2022 14:39:36 +0000,
> >>  static void pci_mask_msi(struct irq_data *data)
> >>  {
> >>  	struct msi_desc *desc = irq_data_get_msi_desc(data);
> >>  
> >>  	pci_msi_mask(desc, BIT(data->irq - desc->irq));
> >> +	cond_mask_parent(data);
> >
> > I find this a bit odd. If anything, I'd rather drop the masking at the
> > PCI level and keep it local to the interrupt controller, because this
> > is likely to be more universal than the equivalent PCI operation
> > (think multi-MSI, for example, which cannot masks individual MSIs).
> >
> > Another thing is that the static key is a global state. Nothing says
> > that masking one way or the other is a universal thing, specially when
> > you have multiple interrupt controllers dealing with MSIs in different
> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
> > at the same time for different PCI RC. OK, they happen to deal with
> > MSIs in the same way, but you hopefully get my point.
> 
> I'm fine with dropping that. I did this because basically all of the
> various ARM PCI/MSI domain implementation have a copy of the same
> functions. Some of them have pointlessly the wrong order because copy &
> pasta is so wonderful....
> 
> So the alternative solution is to provide _ONE_ set of correct callbacks
> and let the domain initialization code override the irq chip callbacks
> of the default PCI/MSI template.

If the various irqchips can tell the core code whether they want
things to be masked at the PCI level or at the irqchip level, this
would be a move in the right direction. For the GIC, I'd definitely
want things masked locally.

What I'd like to get rid off is the double masking, as I agree it is
on the "pretty dumb" side of things.

Thanks,

	M.
  

On Thu, Nov 24 2022 at 13:38, Marc Zyngier wrote:
> On Thu, 24 Nov 2022 13:17:00 +0000,
> Thomas Gleixner <tglx@linutronix.de> wrote:
>> > I find this a bit odd. If anything, I'd rather drop the masking at the
>> > PCI level and keep it local to the interrupt controller, because this
>> > is likely to be more universal than the equivalent PCI operation
>> > (think multi-MSI, for example, which cannot masks individual MSIs).
>> >
>> > Another thing is that the static key is a global state. Nothing says
>> > that masking one way or the other is a universal thing, specially when
>> > you have multiple interrupt controllers dealing with MSIs in different
>> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
>> > at the same time for different PCI RC. OK, they happen to deal with
>> > MSIs in the same way, but you hopefully get my point.
>> 
>> I'm fine with dropping that. I did this because basically all of the
>> various ARM PCI/MSI domain implementation have a copy of the same
>> functions. Some of them have pointlessly the wrong order because copy &
>> pasta is so wonderful....
>> 
>> So the alternative solution is to provide _ONE_ set of correct callbacks
>> and let the domain initialization code override the irq chip callbacks
>> of the default PCI/MSI template.
>
> If the various irqchips can tell the core code whether they want
> things to be masked at the PCI level or at the irqchip level, this
> would be a move in the right direction. For the GIC, I'd definitely
> want things masked locally.
>
> What I'd like to get rid off is the double masking, as I agree it is
> on the "pretty dumb" side of things.

Not necessarily. It mitigates the problem of MSI interrupts which can't
be masked because the implementers decided to spare the gates. MSI
allows that as masking is opt-in...

Let me think about it.

Thanks,

        tglx
  

On Fri, Nov 25 2022 at 01:11, Thomas Gleixner wrote:
> On Thu, Nov 24 2022 at 13:38, Marc Zyngier wrote:
>> On Thu, 24 Nov 2022 13:17:00 +0000,
>> Thomas Gleixner <tglx@linutronix.de> wrote:
>>> > I find this a bit odd. If anything, I'd rather drop the masking at the
>>> > PCI level and keep it local to the interrupt controller, because this
>>> > is likely to be more universal than the equivalent PCI operation
>>> > (think multi-MSI, for example, which cannot masks individual MSIs).
>>> >
>>> > Another thing is that the static key is a global state. Nothing says
>>> > that masking one way or the other is a universal thing, specially when
>>> > you have multiple interrupt controllers dealing with MSIs in different
>>> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
>>> > at the same time for different PCI RC. OK, they happen to deal with
>>> > MSIs in the same way, but you hopefully get my point.
>>> 
>>> I'm fine with dropping that. I did this because basically all of the
>>> various ARM PCI/MSI domain implementation have a copy of the same
>>> functions. Some of them have pointlessly the wrong order because copy &
>>> pasta is so wonderful....
>>> 
>>> So the alternative solution is to provide _ONE_ set of correct callbacks
>>> and let the domain initialization code override the irq chip callbacks
>>> of the default PCI/MSI template.
>>
>> If the various irqchips can tell the core code whether they want
>> things to be masked at the PCI level or at the irqchip level, this
>> would be a move in the right direction. For the GIC, I'd definitely
>> want things masked locally.
>>
>> What I'd like to get rid off is the double masking, as I agree it is
>> on the "pretty dumb" side of things.
>
> Not necessarily. It mitigates the problem of MSI interrupts which can't
> be masked because the implementers decided to spare the gates. MSI
> allows that as masking is opt-in...
>
> Let me think about it.

That really took a while to think about it :)

We have the following cases on the PCI/MSI side:

 1) The MSI[X] entry can be masked

 2) The MSI[X] entry cannot be masked because hardware did not implement
    it, masking is globally disabled due to XEN, masking does not exist
    for this horrible virtual MSI hackery

Now you said:

 "For the GIC, I'd definitely want things masked locally."

I decoded this, that you want to have these interrupts masked at the GIC
level too independent of #1 or #2 above. And then:

 "What I'd like to get rid off is the double masking."

But relying on the GIC alone is not really a good thing IMO. There is no
point to let some confused device send unwanted MSI messages around
without a way to shut it up from the generic code via the regular
mask/unmask callbacks.

On the other hand for PCI/MSI[x] the mask/unmask operations are not in
the hot path as PCI/MSI[x] are strictly edge. Mask/unmask is only
happening on startup, shutdown and when an interrupt arrives after
disable_irq() incremented the lazy disable counter.

For regular interrupt handling mask/unmask is not involved.

So to avoid that global key we can let the parent domain set a new flag,
e.g. MSI_FLAG_PCI_MSI_MASK_PARENT, in msi_parent_ops::supported_flags
and let the PCI/MSI core code query that information when the per device
domain is created and select the appropriate template or fixup the
callbacks after the domain is created.

Does that address your concerns?

Thanks,

        tglx
  

On Mon, 22 May 2023 15:19:39 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Fri, Nov 25 2022 at 01:11, Thomas Gleixner wrote:
> > On Thu, Nov 24 2022 at 13:38, Marc Zyngier wrote:
> >> On Thu, 24 Nov 2022 13:17:00 +0000,
> >> Thomas Gleixner <tglx@linutronix.de> wrote:
> >>> > I find this a bit odd. If anything, I'd rather drop the masking at the
> >>> > PCI level and keep it local to the interrupt controller, because this
> >>> > is likely to be more universal than the equivalent PCI operation
> >>> > (think multi-MSI, for example, which cannot masks individual MSIs).
> >>> >
> >>> > Another thing is that the static key is a global state. Nothing says
> >>> > that masking one way or the other is a universal thing, specially when
> >>> > you have multiple interrupt controllers dealing with MSIs in different
> >>> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame
> >>> > at the same time for different PCI RC. OK, they happen to deal with
> >>> > MSIs in the same way, but you hopefully get my point.
> >>> 
> >>> I'm fine with dropping that. I did this because basically all of the
> >>> various ARM PCI/MSI domain implementation have a copy of the same
> >>> functions. Some of them have pointlessly the wrong order because copy &
> >>> pasta is so wonderful....
> >>> 
> >>> So the alternative solution is to provide _ONE_ set of correct callbacks
> >>> and let the domain initialization code override the irq chip callbacks
> >>> of the default PCI/MSI template.
> >>
> >> If the various irqchips can tell the core code whether they want
> >> things to be masked at the PCI level or at the irqchip level, this
> >> would be a move in the right direction. For the GIC, I'd definitely
> >> want things masked locally.
> >>
> >> What I'd like to get rid off is the double masking, as I agree it is
> >> on the "pretty dumb" side of things.
> >
> > Not necessarily. It mitigates the problem of MSI interrupts which can't
> > be masked because the implementers decided to spare the gates. MSI
> > allows that as masking is opt-in...
> >
> > Let me think about it.
> 
> That really took a while to think about it :)
> 
> We have the following cases on the PCI/MSI side:
> 
>  1) The MSI[X] entry can be masked
> 
>  2) The MSI[X] entry cannot be masked because hardware did not implement
>     it, masking is globally disabled due to XEN, masking does not exist
>     for this horrible virtual MSI hackery

And as a bonus the case of non-PCI MSIs, which are definitely a thing,
and I'd like them to fit in the same model (because life is too short
to do anything else). As for the Xen side, I hope to never have to
care about it for the architecture I care about (I've long proclaimed
Xen/arm64 dead and buried).

> 
> Now you said:
> 
>  "For the GIC, I'd definitely want things masked locally."
> 
> I decoded this, that you want to have these interrupts masked at the GIC
> level too independent of #1 or #2 above. And then:
> 
>  "What I'd like to get rid off is the double masking."
> 
> But relying on the GIC alone is not really a good thing IMO. There is no
> point to let some confused device send unwanted MSI messages around
> without a way to shut it up from the generic code via the regular
> mask/unmask callbacks.

I have a slightly different view of the problem. The device masking is
somehow orthogonal with the masking at the GIC level:

- can the interrupt be generated: this is a device property

- can the interrupt be signalled: this is an interrupt controller
  property

In a way, this is no different from your basic device, such as a
timer: you need both the interrupt generation to be enabled at the
timer level, and the interrupt signalling to be enabled (unmasked) at
the irqchip level.

Today, we conflate the two, because we have either:

- devices that cannot selectively mask interrupts

- interrupt controllers that are limited in what they can mask

and this results in the terrible pattern that's all over the
GIC-related stuff.

> On the other hand for PCI/MSI[x] the mask/unmask operations are not in
> the hot path as PCI/MSI[x] are strictly edge. Mask/unmask is only
> happening on startup, shutdown and when an interrupt arrives after
> disable_irq() incremented the lazy disable counter.
> 
> For regular interrupt handling mask/unmask is not involved.
> 
> So to avoid that global key we can let the parent domain set a new flag,
> e.g. MSI_FLAG_PCI_MSI_MASK_PARENT, in msi_parent_ops::supported_flags
> and let the PCI/MSI core code query that information when the per device
> domain is created and select the appropriate template or fixup the
> callbacks after the domain is created.
> 
> Does that address your concerns?

It does to a certain extent.

But what I'd really like is that in the most common case where the
interrupt controller is capable of masking MSIs, the PCI/MSI
*enabling* becomes the responsibility of the PCI core code and not the
IRQ code.

The IRQ code should ideally only be concerned with the masking of the
interrupt at the irqchip level, and not beyond that. And that'd solve
the Xen problem by merely ignoring it.

If we have HW out there that cannot mask MSIs at the interrupt
controller level, then we'd have to fallback to device-side masking,
which doesn't really work in general (MultiMSI being my favourite
example). My gut feeling is that this is rare, but I'm pretty sure it
exists.

Thanks,

	M.
  

On Tue, May 23 2023 at 11:25, Marc Zyngier wrote:
> On Mon, 22 May 2023 15:19:39 +0100,
> Thomas Gleixner <tglx@linutronix.de> wrote:
>> On the other hand for PCI/MSI[x] the mask/unmask operations are not in
>> the hot path as PCI/MSI[x] are strictly edge. Mask/unmask is only
>> happening on startup, shutdown and when an interrupt arrives after
>> disable_irq() incremented the lazy disable counter.
>> 
>> For regular interrupt handling mask/unmask is not involved.
>> 
>> So to avoid that global key we can let the parent domain set a new flag,
>> e.g. MSI_FLAG_PCI_MSI_MASK_PARENT, in msi_parent_ops::supported_flags
>> and let the PCI/MSI core code query that information when the per device
>> domain is created and select the appropriate template or fixup the
>> callbacks after the domain is created.
>> 
>> Does that address your concerns?
>
> It does to a certain extent.
>
> But what I'd really like is that in the most common case where the
> interrupt controller is capable of masking MSIs, the PCI/MSI
> *enabling* becomes the responsibility of the PCI core code and not the
> IRQ code.
>
> The IRQ code should ideally only be concerned with the masking of the
> interrupt at the irqchip level, and not beyond that. And that'd solve
> the Xen problem by merely ignoring it.
>
> If we have HW out there that cannot mask MSIs at the interrupt
> controller level, then we'd have to fallback to device-side masking,
> which doesn't really work in general (MultiMSI being my favourite
> example). My gut feeling is that this is rare, but I'm pretty sure it
> exists.

Sure. There are 3 parts involved:

      [Device]--->[PCI/MSI]---->[GIC]
                   irqchip      irqchip

Controlling the interrupt machinery in the device happens at the device
driver level and is conceptually independent of the interrupt
manangement code. The device driver has no access to the PCI/MSI irqchip
and all it can do is to enable/disable the source of the interrupt in
the device.

For the interrupt management code the job is to ensure that an interrupt
can be prevented from disrupting the OS operation independent of the
device driver correctness.

As a matter of fact we know that PCI/MSI masking ranges from not
possible over flaky to properly working. So we can't reliably prevent
that a rougue device spams the PCIe bus with messages.

Which means that we should utilize the fact that the next interrupt chip
in the hierarchy can mask reliably. I wish I could disable individual
vectors at the local APIC level on x86...

Now the question is whether we want to make this conditional depending
on what the PCI/MSI[X] hardware advertises or just keep it simple and do
it unconditionally.

Thanks,

        tglx
  

On Tue, 23 May 2023 14:05:56 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> On Tue, May 23 2023 at 11:25, Marc Zyngier wrote:
> > On Mon, 22 May 2023 15:19:39 +0100,
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> >> On the other hand for PCI/MSI[x] the mask/unmask operations are not in
> >> the hot path as PCI/MSI[x] are strictly edge. Mask/unmask is only
> >> happening on startup, shutdown and when an interrupt arrives after
> >> disable_irq() incremented the lazy disable counter.
> >> 
> >> For regular interrupt handling mask/unmask is not involved.
> >> 
> >> So to avoid that global key we can let the parent domain set a new flag,
> >> e.g. MSI_FLAG_PCI_MSI_MASK_PARENT, in msi_parent_ops::supported_flags
> >> and let the PCI/MSI core code query that information when the per device
> >> domain is created and select the appropriate template or fixup the
> >> callbacks after the domain is created.
> >> 
> >> Does that address your concerns?
> >
> > It does to a certain extent.
> >
> > But what I'd really like is that in the most common case where the
> > interrupt controller is capable of masking MSIs, the PCI/MSI
> > *enabling* becomes the responsibility of the PCI core code and not the
> > IRQ code.
> >
> > The IRQ code should ideally only be concerned with the masking of the
> > interrupt at the irqchip level, and not beyond that. And that'd solve
> > the Xen problem by merely ignoring it.
> >
> > If we have HW out there that cannot mask MSIs at the interrupt
> > controller level, then we'd have to fallback to device-side masking,
> > which doesn't really work in general (MultiMSI being my favourite
> > example). My gut feeling is that this is rare, but I'm pretty sure it
> > exists.
> 
> Sure. There are 3 parts involved:
> 
>       [Device]--->[PCI/MSI]---->[GIC]
>                    irqchip      irqchip
> 
> Controlling the interrupt machinery in the device happens at the device
> driver level and is conceptually independent of the interrupt
> manangement code. The device driver has no access to the PCI/MSI irqchip
> and all it can do is to enable/disable the source of the interrupt in
> the device.
> 
> For the interrupt management code the job is to ensure that an interrupt
> can be prevented from disrupting the OS operation independent of the
> device driver correctness.
> 
> As a matter of fact we know that PCI/MSI masking ranges from not
> possible over flaky to properly working. So we can't reliably prevent
> that a rougue device spams the PCIe bus with messages.
> 
> Which means that we should utilize the fact that the next interrupt chip
> in the hierarchy can mask reliably. I wish I could disable individual
> vectors at the local APIC level on x86...
> 
> Now the question is whether we want to make this conditional depending
> on what the PCI/MSI[X] hardware advertises or just keep it simple and do
> it unconditionally.

I think this should be unconditional if the root irqchip (the GIC in
this instance) is capable of it.

So a suggestion where the root irqchip exposes its masking capability,
which upon detection by the upper layer (whateverbusyouwant/MSI) makes
it stop playing with its own device-level mask has my full support
(and now breathe normally).

Thanks,

	M.