From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag
Date: Fri, 23 May 2025 10:06:53 +0100 [thread overview]
Message-ID: <86o6vjelw2.wl-maz@kernel.org> (raw)
In-Reply-To: <875xhzhuup.ffs@tglx>
On Sat, 17 May 2025 20:59:10 +0100,
Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sat, May 17 2025 at 11:30, Marc Zyngier wrote:
> > + /*
> > + * If the parent domain insists on being in charge of masking, obey
> > + * blindly. The default mask/unmask become the shutdown/enable
> > + * callbacks, ensuring that we correctly start/stop the interrupt.
> > + * We make a point in not using the irq_disable() in order to
> > + * preserve the "lazy disable" behaviour.
> > + */
> > + if (info->flags & MSI_FLAG_PCI_MSI_MASK_PARENT) {
> > + chip->irq_shutdown = chip->irq_mask;
> > + chip->irq_enable = chip->irq_unmask;
>
> This is only correct, when the chip does not have dedicated
> irq_shutdown/enable callbacks.
The chip structure provided by the PCI MSI code doesn't provide such
callback, meaning that they are unused for the whole hierarchy.
> And I really hate the asymmetry of this.
So do I, but that's how the lazy disable thing currently works. Drop
the bizarre asymmetry on irq_disable, and we can make this nicely
symmetric as well.
>
> > + chip->irq_mask = irq_chip_mask_parent;
> > + chip->irq_unmask = irq_chip_unmask_parent;
> > + }
>
> I'm still trying to understand, what's the actual problem is you are
> trying to solve.
I'm trying to remove some overhead from machines that don't need to
suffer from this nonsense double masking. Specially in VMs when
masking/unmasking requires *two* extremely costly exits (write +
synchronising read-back). This change reduces the overhead
significantly by only masking where it actually matters.
> MSIs are edge type interrupts, so the interrupt handling hotpath usually
> does not mask at all. The only time masking happens is when it's lazy
> disabled or during affinity changes, which is not the end of the world.
And that's part of the problem. The lazy disable ends up being way
more costly than it should when the interrupt fires during the
"disabled but not quite" phase, and in turn makes the critical section
delineated by disable_irq()/enable_irq() more expensive.
So while, as you put it, it's "not the end of the world", this seems
to me like a valuable optimisation.
Another possible improvement would be to teach the PCI code it can
still rely on masking even when the endpoint is not capable of masking
individual MSIs.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-05-23 9:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-17 10:30 [PATCH] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag Marc Zyngier
2025-05-17 19:59 ` Thomas Gleixner
2025-05-23 9:06 ` Marc Zyngier [this message]
2025-06-30 8:59 ` Thomas Gleixner
2025-09-03 14:04 ` [patch 0/2] PCI/MSI: Avoid PCI level masking during normal operation if requested Thomas Gleixner
2025-09-03 14:04 ` [patch 1/2] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag Thomas Gleixner
2025-09-03 14:04 ` [patch 2/2] PCI/MSI: Remove the conditional parent [un]mask logic Thomas Gleixner
2025-09-03 17:38 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o6vjelw2.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).