From: Jason Gunthorpe <jgg@nvidia.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Logan Gunthorpe <logang@deltatee.com>,
LKML <linux-kernel@vger.kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>, Marc Zygnier <maz@kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
Kevin Tian <kevin.tian@intel.com>,
Megha Dey <megha.dey@intel.com>, Ashok Raj <ashok.raj@intel.com>,
linux-pci@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jon Mason <jdmason@kudzu.us>, Dave Jiang <dave.jiang@intel.com>,
Allen Hubbe <allenbh@gmail.com>,
linux-ntb@googlegroups.com, linux-s390@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
x86@kernel.org, Joerg Roedel <jroedel@suse.de>,
iommu@lists.linux-foundation.org,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()
Date: Mon, 6 Dec 2021 10:43:44 -0400 [thread overview]
Message-ID: <20211206144344.GA4670@nvidia.com> (raw)
In-Reply-To: <87o85v3znb.ffs@tglx>
On Sun, Dec 05, 2021 at 03:16:40PM +0100, Thomas Gleixner wrote:
> On Sat, Dec 04 2021 at 15:20, Thomas Gleixner wrote:
> > On Fri, Dec 03 2021 at 12:41, Jason Gunthorpe wrote:
> > So I need to break that up in a way which caters for both cases, but
> > does neither create a special case for PCI nor for the rest of the
> > universe, i.e. the 1:1 case has to be a subset of the 1:2 case which
> > means all of it is common case. With that solved the storage question
> > becomes a nobrainer.
> >
> > When I looked at it again yesterday while writing mail, I went back to
> > my notes and found the loose ends where I left off. Let me go back and
> > start over from there.
>
> I found out why I stopped looking at it. I came from a similar point of
> view what you were suggesting:
>
> >> If IMS == MSI, then couldn't we conceptually have the dev->irqdomain
> >> completely unable to handle IMS/MSI/MSI-X at all, and instead, when
> >> the driver asks for PCI MSI access we create a new hierarchical
> >> irqdomain and link it to a MSI chip_ops or a MSI-X chip_ops - just as
> >> you outlined for IMS? (again, not saying to do this, but let's ask if
> >> that makes more sense than the current configuration)
>
> Which I shot down with:
>
> > That's not really a good idea because dev->irqdomain is a generic
> > mechanism and not restricted to the PCI use case. Special casing it for
> > PCI is just wrong. Special casing it for all use cases just to please
> > PCI is equally wrong. There is a world outside of PCI and x86.
>
> That argument is actually only partially correct.
I'm not sure I understood your reply? I think we are both agreeing
that dev->irqdomain wants to be a generic mechanism?
I'd say that today we've special cased it to handle PCI. IMHO that is
exactly what pci_msi_create_irq_domain() is doing - it replaces the
chip ops with ops that can *ONLY* do PCI MSI and so dev->irqdomain
becomes PCI only and non-generic.
> After studying my notes and some more code (sigh), it looks feasible
> under certain assumptions, constraints and consequences.
>
> Assumptions:
>
> 1) The irqdomain pointer of PCI devices which is set up during device
> discovery is not used by anything else than infrastructure which
> knows how to handle it.
>
> Of course there is no guarantee, but I'm not that horrified about
> it anymore after chasing the exposure with yet more coccinelle
> scripts.
OK
> Constraints:
>
> 1) This is strictly opt-in and depends on hierarchical irqdomains.
OK
> That means that devices which depend on IMS won't work on anything
> which is not up to date.
OK - I think any pressure to get platforms to update their code is
only positive.
> 2) Guest support is strictly opt-in
>
> The underlying architecture/subarchitecture specific irqdomain has
> to detect at setup time (eventually early boot), whether the
> underlying hypervisor supports it.
>
> The only reasonable way to support that is the availability of
> interrupt remapping via vIOMMU, as we discussed before.
This is talking about IMS specifically because of the legacy issue
where the MSI addr/data pair inside a guest is often completely fake?
> 4) The resulting irqdomain hierarchy would ideally look like this:
>
> VECTOR -> [IOMMU, ROUTING, ...] -> PCI/[MSI/MSI-X/IMS] domains
OK, this matches where I have come from as well
> That does not work in all cases due to architecture and host
> controller constraints, so we might end up with:
>
> VECTOR -> IOMMU -> SHIM -> PCI/[MSI/MSI-X/IMS] domains
OK - I dont' know enough about the architecture/controller details to
imagine what SHIM is, but if it allows keeping the PCI code as purely
PCI code, then great
> 5) The design rules for the device specific IMS irqdomains have to be
> documented and enforced to the extent possible.
>
> Rules which I have in my notes as of today:
>
> - The device specific IMS irq chip / irqdomain has to be strictly
> separated from the rest of the driver code and can only
> interact via the irq chip data which is either per interrupt or
> per device.
It seems OK with the observaion that IDXD and mlx5 will both need to
set 'per-interrupt' data before provisioning the IRQ
> I have some ideas how to enforce these things to go into
> drivers/irqchip/ so they are exposed to scrutiny and not
> burried in some "my device is special" driver code and applied
> by subsystem maintainers before anyone can even look at it.
Means more modules, but OK
> - The irqchip callbacks which can be implemented by these top
> level domains are going to be restricted.
OK - I think it is great that the driver will see a special ops struct
that is 'ops for device's MSI addr/data pair storage'. It makes it
really clear what it is
> - For the irqchip callbacks which are allowed/required the rules
> vs. following down the hierarchy need to be defined and
> enforced.
The driver should be the ultimate origin of the interrupt so it is
always end-point in the hierarchy, opposite the CPU?
I would hope the driver doesn't have an exposure to hierarchy?
> - To achieve that the registration interface will not be based on
> struct irq_chip. This will be a new representation and the core
> will convert that into a proper irq chip which fits into the
> hierarchy. This provides one central place where the hierarchy
> requirements can be handled as they depend on the underlying
> MSI domain (IOMMU, SHIM, etc.). Otherwise any change on that
> would require to chase the IMS irqchips all over the place.
OK, I like this too.
So we have a new concept: 'device MSI storage ops'
Put them along with the xarray holding the msi_descs and you've got my
msi_table :)
> 2) The device centric storage concept will stay as it does not make
> any sense to push it towards drivers and what's worse it would be a
> major pain vs. the not yet up to the task irqdomains and the legacy
> architecture backends to change that. I really have no interrest to
> make the legacy code
>
> It also makes sense because the interrupts are strictly tied to the
> device. They cannot originate from some disconnected layer of thin
> air.
>
> Sorry Jason, no tables for you. :)
How does the driver select with 'device MSI storage ops' it is
requesting a MSI for ?
> 1) I'm going to post part 1-3 of the series once more with the fallout
> and review comments addressed.
OK, I didn't see anything in there that was making anything harder in
this direction
> 5) Implement an IMS user.
>
> The obvious candidate which should be halfways accessible is the
> ath11 PCI driver which falls into that category.
Aiiee:
drivers/net/wireless/ath/ath11k/pci.c: ab_pci->msi_ep_base_data = msi_desc->msg.data;
So, we already have two in-tree PCI IMS devices!!
Agree this makes a lot of sense to focus on some first steps
Along with NTB which is in the same general camp
Thanksm
Jason
next prev parent reply other threads:[~2021-12-06 14:43 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-27 1:23 [patch 00/32] genirq/msi, PCI/MSI: Spring cleaning - Part 2 Thomas Gleixner
2021-11-27 1:23 ` [patch 01/32] genirq/msi: Move descriptor list to struct msi_device_data Thomas Gleixner
2021-11-27 12:19 ` Greg Kroah-Hartman
2021-11-27 1:23 ` [patch 02/32] genirq/msi: Add mutex for MSI list protection Thomas Gleixner
2021-11-27 1:23 ` [patch 03/32] genirq/msi: Provide msi_domain_alloc/free_irqs_descs_locked() Thomas Gleixner
2021-11-27 1:23 ` [patch 04/32] genirq/msi: Provide a set of advanced MSI accessors and iterators Thomas Gleixner
2021-11-28 1:00 ` Jason Gunthorpe
2021-11-28 19:22 ` Thomas Gleixner
2021-11-29 9:26 ` Thomas Gleixner
2021-11-29 14:01 ` Jason Gunthorpe
2021-11-29 14:46 ` Thomas Gleixner
2021-11-27 1:23 ` [patch 05/32] genirq/msi: Provide msi_alloc_msi_desc() and a simple allocator Thomas Gleixner
2021-11-27 1:23 ` [patch 06/32] genirq/msi: Provide domain flags to allocate/free MSI descriptors automatically Thomas Gleixner
2021-11-27 1:23 ` [patch 07/32] genirq/msi: Count the allocated MSI descriptors Thomas Gleixner
2021-11-27 12:19 ` Greg Kroah-Hartman
2021-11-27 19:22 ` Thomas Gleixner
2021-11-27 19:45 ` Thomas Gleixner
2021-11-28 11:07 ` Greg Kroah-Hartman
2021-11-28 19:23 ` Thomas Gleixner
2021-11-27 1:23 ` [patch 08/32] PCI/MSI: Protect MSI operations Thomas Gleixner
2021-11-27 1:23 ` [patch 09/32] PCI/MSI: Use msi_add_msi_desc() Thomas Gleixner
2021-11-27 1:23 ` [patch 10/32] PCI/MSI: Let core code free MSI descriptors Thomas Gleixner
2021-11-27 1:23 ` [patch 11/32] PCI/MSI: Use msi_on_each_desc() Thomas Gleixner
2021-11-27 1:23 ` [patch 12/32] x86/pci/xen: Use msi_for_each_desc() Thomas Gleixner
2021-11-27 1:23 ` [patch 13/32] xen/pcifront: Rework MSI handling Thomas Gleixner
2021-11-27 1:23 ` [patch 14/32] s390/pci: Rework MSI descriptor walk Thomas Gleixner
2021-11-29 10:31 ` Niklas Schnelle
2021-11-29 13:04 ` Thomas Gleixner
2021-11-27 1:23 ` [patch 15/32] powerpc/4xx/hsta: Rework MSI handling Thomas Gleixner
2021-11-27 1:23 ` [patch 16/32] powerpc/cell/axon_msi: Convert to msi_on_each_desc() Thomas Gleixner
2021-11-27 1:23 ` [patch 17/32] powerpc/pasemi/msi: Convert to msi_on_each_dec() Thomas Gleixner
2021-11-27 1:23 ` [patch 18/32] powerpc/fsl_msi: Use msi_for_each_desc() Thomas Gleixner
2021-11-27 1:23 ` [patch 19/32] powerpc/mpic_u3msi: Use msi_for_each-desc() Thomas Gleixner
2021-11-27 1:24 ` [patch 20/32] PCI: hv: Rework MSI handling Thomas Gleixner
2021-11-27 1:24 ` [patch 21/32] NTB/msi: Convert to msi_on_each_desc() Thomas Gleixner
2021-11-29 18:21 ` Logan Gunthorpe
2021-11-29 20:51 ` Thomas Gleixner
2021-11-29 22:27 ` Logan Gunthorpe
2021-11-29 22:50 ` Dave Jiang
2021-11-29 23:31 ` Jason Gunthorpe
2021-11-29 23:52 ` Logan Gunthorpe
2021-11-30 0:01 ` Jason Gunthorpe
2021-11-30 0:29 ` Thomas Gleixner
2021-11-30 19:21 ` Logan Gunthorpe
2021-11-30 19:48 ` Thomas Gleixner
2021-11-30 20:14 ` Logan Gunthorpe
2021-11-30 20:28 ` Jason Gunthorpe
2021-11-30 21:23 ` Thomas Gleixner
2021-12-01 0:17 ` Jason Gunthorpe
2021-12-01 10:16 ` Thomas Gleixner
2021-12-01 13:00 ` Jason Gunthorpe
2021-12-01 17:35 ` Thomas Gleixner
2021-12-01 18:14 ` Jason Gunthorpe
2021-12-01 18:46 ` Logan Gunthorpe
2021-12-01 20:21 ` Thomas Gleixner
2021-12-02 0:01 ` Thomas Gleixner
2021-12-02 13:55 ` Jason Gunthorpe
2021-12-02 14:23 ` Greg Kroah-Hartman
2021-12-02 14:45 ` Jason Gunthorpe
2021-12-02 19:25 ` Thomas Gleixner
2021-12-02 20:00 ` Jason Gunthorpe
2021-12-02 22:31 ` Thomas Gleixner
2021-12-03 0:37 ` Jason Gunthorpe
2021-12-03 15:07 ` Thomas Gleixner
2021-12-03 16:41 ` Jason Gunthorpe
2021-12-04 14:20 ` Thomas Gleixner
2021-12-05 14:16 ` Thomas Gleixner
2021-12-06 14:43 ` Jason Gunthorpe [this message]
2021-12-06 15:47 ` Thomas Gleixner
2021-12-06 17:00 ` Jason Gunthorpe
2021-12-06 20:28 ` Thomas Gleixner
2021-12-06 21:06 ` Jason Gunthorpe
2021-12-06 22:21 ` Thomas Gleixner
2021-12-06 14:19 ` Jason Gunthorpe
2021-12-06 15:06 ` Thomas Gleixner
2021-12-09 6:26 ` Tian, Kevin
2021-12-09 9:03 ` Thomas Gleixner
2021-12-09 12:17 ` Tian, Kevin
2021-12-09 15:57 ` Thomas Gleixner
2021-12-10 7:37 ` Tian, Kevin
2021-12-09 5:41 ` Tian, Kevin
2021-12-09 5:47 ` Jason Wang
2021-12-01 16:28 ` Dave Jiang
2021-12-01 18:41 ` Thomas Gleixner
2021-12-01 18:47 ` Dave Jiang
2021-12-01 20:25 ` Thomas Gleixner
2021-12-01 21:21 ` Dave Jiang
2021-12-01 21:44 ` Thomas Gleixner
2021-12-01 21:49 ` Dave Jiang
2021-12-01 22:03 ` Thomas Gleixner
2021-12-01 22:53 ` Dave Jiang
2021-12-01 23:57 ` Thomas Gleixner
2021-12-09 5:23 ` Tian, Kevin
2021-12-09 8:37 ` Thomas Gleixner
2021-12-09 12:31 ` Tian, Kevin
2021-12-09 16:21 ` Jason Gunthorpe
2021-12-09 20:32 ` Thomas Gleixner
2021-12-09 20:58 ` Jason Gunthorpe
2021-12-09 22:09 ` Thomas Gleixner
2021-12-10 0:26 ` Thomas Gleixner
2021-12-10 7:29 ` Tian, Kevin
2021-12-10 12:13 ` Thomas Gleixner
2021-12-11 8:06 ` Tian, Kevin
2021-12-10 12:39 ` Jason Gunthorpe
2021-12-10 19:00 ` Thomas Gleixner
2021-12-11 7:44 ` Tian, Kevin
2021-12-11 13:04 ` Thomas Gleixner
2021-12-12 1:56 ` Tian, Kevin
2021-12-12 20:55 ` Thomas Gleixner
2021-12-12 23:37 ` Jason Gunthorpe
2021-12-13 7:50 ` Tian, Kevin
2021-12-11 7:52 ` Tian, Kevin
2021-12-12 0:12 ` Thomas Gleixner
2021-12-12 2:14 ` Tian, Kevin
2021-12-12 20:50 ` Thomas Gleixner
2021-12-12 23:42 ` Jason Gunthorpe
2021-12-10 7:36 ` Tian, Kevin
2021-12-10 12:30 ` Jason Gunthorpe
2021-12-12 6:44 ` Mika Penttilä
2021-12-12 23:27 ` Jason Gunthorpe
2021-12-01 14:52 ` Thomas Gleixner
2021-12-01 15:11 ` Jason Gunthorpe
2021-12-01 18:37 ` Thomas Gleixner
2021-12-01 18:47 ` Jason Gunthorpe
2021-12-01 20:26 ` Thomas Gleixner
2021-11-27 1:24 ` [patch 22/32] soc: ti: ti_sci_inta_msi: Rework MSI descriptor allocation Thomas Gleixner
2021-11-27 1:24 ` [patch 23/32] soc: ti: ti_sci_inta_msi: Remove ti_sci_inta_msi_domain_free_irqs() Thomas Gleixner
2021-11-27 1:24 ` [patch 24/32] bus: fsl-mc-msi: Simplify MSI descriptor handling Thomas Gleixner
2021-11-27 1:24 ` [patch 25/32] platform-msi: Let core code handle MSI descriptors Thomas Gleixner
2021-11-27 1:24 ` [patch 26/32] platform-msi: Simplify platform device MSI code Thomas Gleixner
2021-11-27 1:24 ` [patch 27/32] genirq/msi: Make interrupt allocation less convoluted Thomas Gleixner
2021-11-27 1:24 ` [patch 28/32] genirq/msi: Convert to new functions Thomas Gleixner
2021-11-27 1:24 ` [patch 29/32] genirq/msi: Mop up old interfaces Thomas Gleixner
2021-11-27 1:24 ` [patch 30/32] genirq/msi: Add abuse prevention comment to msi header Thomas Gleixner
2021-11-27 1:24 ` [patch 31/32] genirq/msi: Simplify sysfs handling Thomas Gleixner
2021-11-27 12:32 ` Greg Kroah-Hartman
2021-11-27 19:31 ` Thomas Gleixner
2021-11-28 11:07 ` Greg Kroah-Hartman
2021-11-28 19:33 ` Thomas Gleixner
2021-11-27 1:24 ` [patch 32/32] genirq/msi: Convert storage to xarray Thomas Gleixner
2021-11-27 12:33 ` Greg Kroah-Hartman
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=20211206144344.GA4670@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=allenbh@gmail.com \
--cc=ashok.raj@intel.com \
--cc=borntraeger@de.ibm.com \
--cc=dave.jiang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hca@linux.ibm.com \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jdmason@kudzu.us \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntb@googlegroups.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=maz@kernel.org \
--cc=megha.dey@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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).