From: Dave Jiang <dave.jiang@intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Jason Gunthorpe <jgg@nvidia.com> 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>, 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 Subject: Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc() Date: Wed, 1 Dec 2021 09:28:52 -0700 [thread overview] Message-ID: <8c2262ba-173e-0007-bc4c-94ec54b2847d@intel.com> (raw) In-Reply-To: <87mtlkaauo.ffs@tglx> On 12/1/2021 3:16 AM, Thomas Gleixner wrote: > Jason, > > CC+ IOMMU folks > > On Tue, Nov 30 2021 at 20:17, Jason Gunthorpe wrote: >> On Tue, Nov 30, 2021 at 10:23:16PM +0100, Thomas Gleixner wrote: >>> The real problem is where to store the MSI descriptors because the PCI >>> device has its own real PCI/MSI-X interrupts which means it still shares >>> the storage space. >> Er.. I never realized that just looking at the patches :| >> >> That is relevant to all real "IMS" users. IDXD escaped this because >> it, IMHO, wrongly used the mdev with the IRQ layer. The mdev is purely >> a messy artifact of VFIO, it should not be required to make the IRQ >> layers work. >> I don't think it makes sense that the msi_desc would point to a mdev, >> the iommu layer consumes the msi_desc_to_dev(), it really should point >> to the physical device that originates the message with a proper >> iommu ops/data/etc. > Looking at the device slices as subdevices with their own struct device > makes a lot of sense from the conceptual level. That makes is pretty > much obvious to manage the MSIs of those devices at this level like we > do for any other device. > > Whether mdev is the right encapsulation for these subdevices is an > orthogonal problem. > > I surely agree that msi_desc::dev is an interesting question, but we > already have this disconnect of msi_desc::dev and DMA today due to DMA > aliasing. I haven't looked at that in detail yet, but of course the > alias handling is substantially different accross the various IOMMU > implementations. > > Though I fear there is also a use case for MSI-X and IMS tied to the > same device. That network card you are talking about might end up using > MSI-X for a control block and then IMS for the actual network queues > when it is used as physical function device as a whole, but that's > conceptually a different case. Hi Thomas. This is actually the IDXD usage for a mediated device passed to a guest kernel when we plumb the pass through of IMS to the guest rather than doing previous implementation of having a MSIX vector on guest backed by IMS. The control block for the mediated device is emulated and therefore an emulated MSIX vector will be surfaced as vector 0. However the queues will backed by IMS vectors. So we end up needing MSIX and IMS coexist running on the guest kernel for the same device. DJ > >>> I'm currently tending to partition the index space in the xarray: >>> >>> 0x00000000 - 0x0000ffff PCI/MSI-X >>> 0x00010000 - 0x0001ffff NTB >> It is OK, with some xarray work it can be range allocating & reserving >> so that the msi_domain_alloc_irqs() flows can carve out chunks of the >> number space.. >> >> Another view is the msi_domain_alloc_irqs() flows should have their >> own xarrays.. > Yes, I was thinking about that as well. The trivial way would be: > > struct xarray store[MSI_MAX_STORES]; > > and then have a store index for each allocation domain. With the > proposed encapsulation of the xarray handling that's definitely > feasible. Whether that buys much is a different question. Let me think > about it some more. > >>> which is feasible now with the range modifications and way simpler to do >>> with xarray than with the linked list. >> Indeed! > I'm glad you like the approach. > > Thanks, > > tglx > >
WARNING: multiple messages have this Message-ID (diff)
From: Dave Jiang <dave.jiang@intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Jason Gunthorpe <jgg@nvidia.com> Cc: Allen Hubbe <allenbh@gmail.com>, linux-s390@vger.kernel.org, Kevin Tian <kevin.tian@intel.com>, x86@kernel.org, Ashok Raj <ashok.raj@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marc Zygnier <maz@kernel.org>, Heiko Carstens <hca@linux.ibm.com>, LKML <linux-kernel@vger.kernel.org>, iommu@lists.linux-foundation.org, Christian Borntraeger <borntraeger@de.ibm.com>, Alex Williamson <alex.williamson@redhat.com>, Joerg Roedel <jroedel@suse.de>, Bjorn Helgaas <helgaas@kernel.org>, linux-pci@vger.kernel.org, linux-ntb@googlegroups.com, Logan Gunthorpe <logang@deltatee.com>, Megha Dey <megha.dey@intel.com> Subject: Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc() Date: Wed, 1 Dec 2021 09:28:52 -0700 [thread overview] Message-ID: <8c2262ba-173e-0007-bc4c-94ec54b2847d@intel.com> (raw) In-Reply-To: <87mtlkaauo.ffs@tglx> On 12/1/2021 3:16 AM, Thomas Gleixner wrote: > Jason, > > CC+ IOMMU folks > > On Tue, Nov 30 2021 at 20:17, Jason Gunthorpe wrote: >> On Tue, Nov 30, 2021 at 10:23:16PM +0100, Thomas Gleixner wrote: >>> The real problem is where to store the MSI descriptors because the PCI >>> device has its own real PCI/MSI-X interrupts which means it still shares >>> the storage space. >> Er.. I never realized that just looking at the patches :| >> >> That is relevant to all real "IMS" users. IDXD escaped this because >> it, IMHO, wrongly used the mdev with the IRQ layer. The mdev is purely >> a messy artifact of VFIO, it should not be required to make the IRQ >> layers work. >> I don't think it makes sense that the msi_desc would point to a mdev, >> the iommu layer consumes the msi_desc_to_dev(), it really should point >> to the physical device that originates the message with a proper >> iommu ops/data/etc. > Looking at the device slices as subdevices with their own struct device > makes a lot of sense from the conceptual level. That makes is pretty > much obvious to manage the MSIs of those devices at this level like we > do for any other device. > > Whether mdev is the right encapsulation for these subdevices is an > orthogonal problem. > > I surely agree that msi_desc::dev is an interesting question, but we > already have this disconnect of msi_desc::dev and DMA today due to DMA > aliasing. I haven't looked at that in detail yet, but of course the > alias handling is substantially different accross the various IOMMU > implementations. > > Though I fear there is also a use case for MSI-X and IMS tied to the > same device. That network card you are talking about might end up using > MSI-X for a control block and then IMS for the actual network queues > when it is used as physical function device as a whole, but that's > conceptually a different case. Hi Thomas. This is actually the IDXD usage for a mediated device passed to a guest kernel when we plumb the pass through of IMS to the guest rather than doing previous implementation of having a MSIX vector on guest backed by IMS. The control block for the mediated device is emulated and therefore an emulated MSIX vector will be surfaced as vector 0. However the queues will backed by IMS vectors. So we end up needing MSIX and IMS coexist running on the guest kernel for the same device. DJ > >>> I'm currently tending to partition the index space in the xarray: >>> >>> 0x00000000 - 0x0000ffff PCI/MSI-X >>> 0x00010000 - 0x0001ffff NTB >> It is OK, with some xarray work it can be range allocating & reserving >> so that the msi_domain_alloc_irqs() flows can carve out chunks of the >> number space.. >> >> Another view is the msi_domain_alloc_irqs() flows should have their >> own xarrays.. > Yes, I was thinking about that as well. The trivial way would be: > > struct xarray store[MSI_MAX_STORES]; > > and then have a store index for each allocation domain. With the > proposed encapsulation of the xarray handling that's definitely > feasible. Whether that buys much is a different question. Let me think > about it some more. > >>> which is feasible now with the range modifications and way simpler to do >>> with xarray than with the linked list. >> Indeed! > I'm glad you like the approach. > > Thanks, > > tglx > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-12-01 16:30 UTC|newest] Thread overview: 255+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-27 1:22 [patch 00/32] genirq/msi, PCI/MSI: Spring cleaning - Part 2 Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 01/32] genirq/msi: Move descriptor list to struct msi_device_data Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 12:19 ` Greg Kroah-Hartman 2021-11-27 1:22 ` [patch 02/32] genirq/msi: Add mutex for MSI list protection Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 03/32] genirq/msi: Provide msi_domain_alloc/free_irqs_descs_locked() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 04/32] genirq/msi: Provide a set of advanced MSI accessors and iterators Thomas Gleixner 2021-11-27 1:23 ` 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:22 ` [patch 05/32] genirq/msi: Provide msi_alloc_msi_desc() and a simple allocator Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 06/32] genirq/msi: Provide domain flags to allocate/free MSI descriptors automatically Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 07/32] genirq/msi: Count the allocated MSI descriptors Thomas Gleixner 2021-11-27 1:23 ` 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:22 ` [patch 08/32] PCI/MSI: Protect MSI operations Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 09/32] PCI/MSI: Use msi_add_msi_desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 10/32] PCI/MSI: Let core code free MSI descriptors Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 11/32] PCI/MSI: Use msi_on_each_desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 12/32] x86/pci/xen: Use msi_for_each_desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 13/32] xen/pcifront: Rework MSI handling Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 14/32] s390/pci: Rework MSI descriptor walk Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-29 10:31 ` Niklas Schnelle 2021-11-29 13:04 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 15/32] powerpc/4xx/hsta: Rework MSI handling Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 16/32] powerpc/cell/axon_msi: Convert to msi_on_each_desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 17/32] powerpc/pasemi/msi: Convert to msi_on_each_dec() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 18/32] powerpc/fsl_msi: Use msi_for_each_desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 19/32] powerpc/mpic_u3msi: Use msi_for_each-desc() Thomas Gleixner 2021-11-27 1:23 ` Thomas Gleixner 2021-11-27 1:22 ` [patch 20/32] PCI: hv: Rework MSI handling Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 21/32] NTB/msi: Convert to msi_on_each_desc() Thomas Gleixner 2021-11-27 1:24 ` 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 10:16 ` Thomas Gleixner 2021-12-01 13:00 ` Jason Gunthorpe 2021-12-01 13:00 ` Jason Gunthorpe via iommu 2021-12-01 17:35 ` Thomas Gleixner 2021-12-01 17:35 ` Thomas Gleixner 2021-12-01 18:14 ` Jason Gunthorpe 2021-12-01 18:14 ` Jason Gunthorpe via iommu 2021-12-01 18:46 ` Logan Gunthorpe 2021-12-01 18:46 ` Logan Gunthorpe 2021-12-01 20:21 ` Thomas Gleixner 2021-12-01 20:21 ` Thomas Gleixner 2021-12-02 0:01 ` Thomas Gleixner 2021-12-02 0:01 ` Thomas Gleixner 2021-12-02 13:55 ` Jason Gunthorpe 2021-12-02 13:55 ` Jason Gunthorpe via iommu 2021-12-02 14:23 ` Greg Kroah-Hartman 2021-12-02 14:23 ` Greg Kroah-Hartman 2021-12-02 14:45 ` Jason Gunthorpe 2021-12-02 14:45 ` Jason Gunthorpe via iommu 2021-12-02 19:25 ` Thomas Gleixner 2021-12-02 19:25 ` Thomas Gleixner 2021-12-02 20:00 ` Jason Gunthorpe 2021-12-02 20:00 ` Jason Gunthorpe via iommu 2021-12-02 22:31 ` Thomas Gleixner 2021-12-02 22:31 ` Thomas Gleixner 2021-12-03 0:37 ` Jason Gunthorpe 2021-12-03 0:37 ` Jason Gunthorpe via iommu 2021-12-03 15:07 ` Thomas Gleixner 2021-12-03 15:07 ` Thomas Gleixner 2021-12-03 16:41 ` Jason Gunthorpe 2021-12-03 16:41 ` Jason Gunthorpe via iommu 2021-12-04 14:20 ` Thomas Gleixner 2021-12-04 14:20 ` Thomas Gleixner 2021-12-05 14:16 ` Thomas Gleixner 2021-12-05 14:16 ` Thomas Gleixner 2021-12-06 14:43 ` Jason Gunthorpe 2021-12-06 14:43 ` Jason Gunthorpe via iommu 2021-12-06 15:47 ` Thomas Gleixner 2021-12-06 15:47 ` Thomas Gleixner 2021-12-06 17:00 ` Jason Gunthorpe via iommu 2021-12-06 17:00 ` Jason Gunthorpe 2021-12-06 20:28 ` Thomas Gleixner 2021-12-06 20:28 ` Thomas Gleixner 2021-12-06 21:06 ` Jason Gunthorpe 2021-12-06 21:06 ` Jason Gunthorpe via iommu 2021-12-06 22:21 ` Thomas Gleixner 2021-12-06 22:21 ` Thomas Gleixner 2021-12-06 14:19 ` Jason Gunthorpe 2021-12-06 14:19 ` Jason Gunthorpe via iommu 2021-12-06 15:06 ` Thomas Gleixner 2021-12-06 15:06 ` Thomas Gleixner 2021-12-09 6:26 ` Tian, Kevin 2021-12-09 6:26 ` Tian, Kevin 2021-12-09 9:03 ` Thomas Gleixner 2021-12-09 9:03 ` Thomas Gleixner 2021-12-09 12:17 ` Tian, Kevin 2021-12-09 12:17 ` Tian, Kevin 2021-12-09 15:57 ` Thomas Gleixner 2021-12-09 15:57 ` Thomas Gleixner 2021-12-10 7:37 ` Tian, Kevin 2021-12-10 7:37 ` Tian, Kevin 2021-12-09 5:41 ` Tian, Kevin 2021-12-09 5:41 ` Tian, Kevin 2021-12-09 5:47 ` Jason Wang 2021-12-09 5:47 ` Jason Wang 2021-12-01 16:28 ` Dave Jiang [this message] 2021-12-01 16:28 ` Dave Jiang 2021-12-01 18:41 ` Thomas Gleixner 2021-12-01 18:41 ` Thomas Gleixner 2021-12-01 18:47 ` Dave Jiang 2021-12-01 18:47 ` Dave Jiang 2021-12-01 20:25 ` Thomas Gleixner 2021-12-01 20:25 ` Thomas Gleixner 2021-12-01 21:21 ` Dave Jiang 2021-12-01 21:21 ` Dave Jiang 2021-12-01 21:44 ` Thomas Gleixner 2021-12-01 21:44 ` Thomas Gleixner 2021-12-01 21:49 ` Dave Jiang 2021-12-01 21:49 ` Dave Jiang 2021-12-01 22:03 ` Thomas Gleixner 2021-12-01 22:03 ` Thomas Gleixner 2021-12-01 22:53 ` Dave Jiang 2021-12-01 22:53 ` Dave Jiang 2021-12-01 23:57 ` Thomas Gleixner 2021-12-01 23:57 ` Thomas Gleixner 2021-12-09 5:23 ` Tian, Kevin 2021-12-09 5:23 ` Tian, Kevin 2021-12-09 8:37 ` Thomas Gleixner 2021-12-09 8:37 ` Thomas Gleixner 2021-12-09 12:31 ` Tian, Kevin 2021-12-09 12:31 ` Tian, Kevin 2021-12-09 16:21 ` Jason Gunthorpe 2021-12-09 16:21 ` Jason Gunthorpe via iommu 2021-12-09 20:32 ` Thomas Gleixner 2021-12-09 20:32 ` Thomas Gleixner 2021-12-09 20:58 ` Jason Gunthorpe 2021-12-09 20:58 ` Jason Gunthorpe via iommu 2021-12-09 22:09 ` Thomas Gleixner 2021-12-09 22:09 ` Thomas Gleixner 2021-12-10 0:26 ` Thomas Gleixner 2021-12-10 0:26 ` Thomas Gleixner 2021-12-10 7:29 ` Tian, Kevin 2021-12-10 7:29 ` Tian, Kevin 2021-12-10 12:13 ` Thomas Gleixner 2021-12-10 12:13 ` Thomas Gleixner 2021-12-11 8:06 ` Tian, Kevin 2021-12-11 8:06 ` Tian, Kevin 2021-12-10 12:39 ` Jason Gunthorpe 2021-12-10 12:39 ` Jason Gunthorpe via iommu 2021-12-10 19:00 ` Thomas Gleixner 2021-12-10 19:00 ` Thomas Gleixner 2021-12-11 7:44 ` Tian, Kevin 2021-12-11 7:44 ` Tian, Kevin 2021-12-11 13:04 ` Thomas Gleixner 2021-12-11 13:04 ` Thomas Gleixner 2021-12-12 1:56 ` Tian, Kevin 2021-12-12 1:56 ` Tian, Kevin 2021-12-12 20:55 ` Thomas Gleixner 2021-12-12 20:55 ` Thomas Gleixner 2021-12-12 23:37 ` Jason Gunthorpe 2021-12-12 23:37 ` Jason Gunthorpe via iommu 2021-12-13 7:50 ` Tian, Kevin 2021-12-13 7:50 ` Tian, Kevin 2022-09-15 9:24 ` Tian, Kevin 2022-09-20 14:09 ` Jason Gunthorpe 2022-09-21 7:57 ` Tian, Kevin 2022-09-21 12:48 ` Jason Gunthorpe 2022-09-22 5:11 ` Tian, Kevin 2022-09-22 12:13 ` Jason Gunthorpe 2022-09-22 22:42 ` Tian, Kevin 2022-09-23 13:26 ` Jason Gunthorpe 2021-12-11 7:52 ` Tian, Kevin 2021-12-11 7:52 ` Tian, Kevin 2021-12-12 0:12 ` Thomas Gleixner 2021-12-12 0:12 ` Thomas Gleixner 2021-12-12 2:14 ` Tian, Kevin 2021-12-12 2:14 ` Tian, Kevin 2021-12-12 20:50 ` Thomas Gleixner 2021-12-12 20:50 ` Thomas Gleixner 2021-12-12 23:42 ` Jason Gunthorpe 2021-12-12 23:42 ` Jason Gunthorpe via iommu 2021-12-10 7:36 ` Tian, Kevin 2021-12-10 7:36 ` Tian, Kevin 2021-12-10 12:30 ` Jason Gunthorpe 2021-12-10 12:30 ` Jason Gunthorpe via iommu 2021-12-12 6:44 ` Mika Penttilä 2021-12-12 6:44 ` Mika Penttilä 2021-12-12 23:27 ` Jason Gunthorpe 2021-12-12 23:27 ` Jason Gunthorpe via iommu 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 2022-12-05 18:25 ` [tip: irq/core] PCI/MSI: Provide post-enable dynamic allocation interfaces for MSI-X tip-bot2 for Thomas Gleixner 2022-12-05 21:41 ` tip-bot2 for Thomas Gleixner 2021-11-27 1:23 ` [patch 22/32] soc: ti: ti_sci_inta_msi: Rework MSI descriptor allocation Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 23/32] soc: ti: ti_sci_inta_msi: Remove ti_sci_inta_msi_domain_free_irqs() Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 24/32] bus: fsl-mc-msi: Simplify MSI descriptor handling Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 25/32] platform-msi: Let core code handle MSI descriptors Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 26/32] platform-msi: Simplify platform device MSI code Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 27/32] genirq/msi: Make interrupt allocation less convoluted Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 28/32] genirq/msi: Convert to new functions Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 29/32] genirq/msi: Mop up old interfaces Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 30/32] genirq/msi: Add abuse prevention comment to msi header Thomas Gleixner 2021-11-27 1:24 ` Thomas Gleixner 2021-11-27 1:23 ` [patch 31/32] genirq/msi: Simplify sysfs handling Thomas Gleixner 2021-11-27 1:24 ` 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:23 ` [patch 32/32] genirq/msi: Convert storage to xarray Thomas Gleixner 2021-11-27 1:24 ` 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=8c2262ba-173e-0007-bc4c-94ec54b2847d@intel.com \ --to=dave.jiang@intel.com \ --cc=alex.williamson@redhat.com \ --cc=allenbh@gmail.com \ --cc=ashok.raj@intel.com \ --cc=borntraeger@de.ibm.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=jgg@nvidia.com \ --cc=jroedel@suse.de \ --cc=kevin.tian@intel.com \ --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: linkBe 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.