From: Marc Zyngier <maz@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Zenghui Yu <yuzenghui@huawei.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Thomas Gleixner <tglx@linutronix.de>,
Sascha Bischoff <sascha.bischoff@arm.com>,
Timothy Hayes <timothy.hayes@arm.com>
Subject: Re: [PATCH v2 3/5] genirq/msi: Move prepare() call to per-device allocation
Date: Tue, 03 Jun 2025 14:09:50 +0100 [thread overview]
Message-ID: <87jz5tdl9d.wl-maz@kernel.org> (raw)
In-Reply-To: <aD7B96BiSb6mK9Bj@lpieralisi>
On Tue, 03 Jun 2025 10:35:51 +0100,
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> On Tue, Jun 03, 2025 at 04:22:47PM +0800, Zenghui Yu wrote:
> > > + domain->dev = dev;
> > > + dev->msi.data->__domains[domid].domain = domain;
> > > +
> > > + if (msi_domain_prepare_irqs(domain, dev, hwsize, &bundle->alloc_info)) {
> >
> > Does it work for MSI?
>
> This means that it does not work for MSI for you as it stands, right ?
>
> If you spotted an issue, thanks for that, report it fully please.
Honestly, you're barking up the wrong tree. Zenghui points us to a
glaring bug in the core code, with detailed information on what could
go wrong, as well as what is wrong in the code. It doesn't get better
than that.
The usual level of bug reports is "its b0rken", sometimes followed by
a trace with lots of hex and no information. Spot the difference?
>
> > hwsize is 1 in the MSI case, without taking pci_msi_vec_count() into account.
> >
> > bool pci_setup_msi_device_domain(struct pci_dev *pdev)
> > {
> > [...]
> >
> > return pci_create_device_domain(pdev, &pci_msi_template, 1);
>
> I had a stab at it with GICv5 models and an MSI capable device and this indeed
> calls the ITS msi_prepare() callback with 1 as vector count, so we size
> the device tables wrongly.
Not wrongly. Exactly as instructed.
>
> The question is why pci_create_device_domain() is called here with
> hwsize == 1. Probably, before this series, the ITS MSI parent code was
> fixing the size up so we did not notice, I need to check.
The GICv3 ITS code would upgrade the vector count to the next power of
two (one bit of EID space -> 2 MSIs), but with the device domain
squarely set to 1, the endpoint driver would never get more. It is
prepared to fail gracefully though, hence nothing really breaks.
I don't think this patch makes anything regress though. Commit
15c72f824b327 seems to be the offending one. If Zenghui confirms that
the hack I posted separately works for him, I'll follow up with a
"real" patch.
M.
--
Jazz isn't dead. It just smells funny.
next prev parent reply other threads:[~2025-06-03 13:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 16:31 [PATCH v2 0/5] genirq/msi: Fix device MSI prepare/alloc sequencing Marc Zyngier
2025-05-13 16:31 ` [PATCH v2 1/5] genirq/msi: Add .msi_teardown() callback as the reverse of .msi_prepare() Marc Zyngier
2025-05-16 10:02 ` [tip: irq/msi] " tip-bot2 for Marc Zyngier
2025-05-13 16:31 ` [PATCH v2 2/5] irqchip/gic-v3-its: Implement .msi_teardown() callback Marc Zyngier
2025-05-16 10:02 ` [tip: irq/msi] " tip-bot2 for Marc Zyngier
2025-05-13 16:31 ` [PATCH v2 3/5] genirq/msi: Move prepare() call to per-device allocation Marc Zyngier
2025-05-16 10:02 ` [tip: irq/msi] " tip-bot2 for Marc Zyngier
2025-06-03 8:22 ` [PATCH v2 3/5] " Zenghui Yu
2025-06-03 9:35 ` Lorenzo Pieralisi
2025-06-03 13:09 ` Marc Zyngier [this message]
2025-06-03 14:37 ` Lorenzo Pieralisi
2025-06-04 1:52 ` Zenghui Yu
2025-06-03 12:50 ` Marc Zyngier
2025-06-03 13:07 ` Zenghui Yu
2025-06-03 13:27 ` Marc Zyngier
2025-06-03 13:29 ` Lorenzo Pieralisi
2025-06-03 14:03 ` Marc Zyngier
2025-06-03 14:08 ` Marc Zyngier
2025-05-13 16:31 ` [PATCH v2 4/5] genirq/msi: Engage the .msi_teardown() callback on domain removal Marc Zyngier
2025-05-16 10:02 ` [tip: irq/msi] " tip-bot2 for Marc Zyngier
2025-05-13 16:31 ` [PATCH v2 5/5] irqchip/gic-v3-its: Use allocation size from the prepare call Marc Zyngier
2025-05-16 10:02 ` [tip: irq/msi] " tip-bot2 for Marc Zyngier
2025-05-18 18:53 ` [PATCH v2 5/5] " Thomas Gleixner
2025-05-19 10:15 ` Marc Zyngier
2025-05-19 12:16 ` Thomas Gleixner
2025-05-19 14:28 ` Marc Zyngier
2025-05-21 15:29 ` Thomas Gleixner
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=87jz5tdl9d.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=sascha.bischoff@arm.com \
--cc=tglx@linutronix.de \
--cc=timothy.hayes@arm.com \
--cc=yuzenghui@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.