> From: Jason Gunthorpe
> Sent: Thursday, September 28, 2023 7:48 AM
>
> Move the global static blocked domain to the ops and convert the
> unmanaged
> domain to domain_alloc_paging.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, September 28, 2023 7:48 AM
>
> Following the pattern of identity domains, just assign the BLOCKED domain
> global statics to a value in ops. Update the core code to use the global
> static directly.
>
> Update powerpc to use the new scheme and remove its
> From: Jason Gunthorpe
> Sent: Thursday, September 28, 2023 7:48 AM
>
> The global static should pre-define the type and the NOP free function can
> be now left as NULL.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, September 28, 2023 7:48 AM
>
> Trivially migrate to the ops->blocked_domain for the existing global
> static.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Anshuman Khandual
> Sent: Wednesday, July 19, 2023 11:04 AM
>
> On 7/18/23 13:26, Alistair Popple wrote:
> > The main change is to move secondary TLB invalidation mmu notifier
> > callbacks into the architecture specific TLB flushing functions. This
> > makes secondary TLB invalidation mo
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is a step toward making __iommu_probe_device() self contained.
>
> It should, under proper locking, check if the device is already associated
> with an iommu driver and resolve parallel probes. All but one of the
> caller
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> No reason to open code this, use the proper helper functions.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is the only caller, and it doesn't need the generality of the
> function. We already know there is no iommu_group, so it is simply two
> function calls.
>
> Moving it here allows the following patches to split the logic i
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Instead of returning the struct group_device and then later freeing it, do
> the entire free under the group->mutex and defer only putting the
> iommu_group.
>
> It is safe to remove the sysfs_links and free memory while holdi
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> +static int iommu_init_driver(struct device *dev, const struct iommu_ops
> *ops)
would iommu_init_device() better fit the purpose?
otherwise,
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> It makes logical sense that once the driver is attached to the device the
> sysfs links appear, even if we haven't fully created the group_device or
> attached the device to a domain.
>
> Fix the missing error handling on sysf
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> These are not used outside iommu.c, they should not be available to
> modular code.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Have release fully clean up the iommu related parts of the struct device,
> no matter what state they are in.
>
> POWER creates iommu_groups without drivers attached, and the next patch
> removes the open-coding of this same c
> From: Thomas Gleixner
> Sent: Friday, November 11, 2022 9:54 PM
>
> PCI/MSI and PCI/MSI-X are mutually exclusive, but the MSI-X enable code
> lacks a check for already enabled MSI.
>
> Signed-off-by: Thomas Gleixner
> ---
> drivers/pci/msi/msi.c |5 +
> 1 file changed, 5 insertions(+
> From: Thomas Gleixner
> Sent: Friday, November 11, 2022 9:55 PM
>
> @@ -785,7 +786,7 @@ int __pci_enable_msix_range(struct pci_d
> return -ENOSPC;
> }
>
> - rc = __pci_enable_msix(dev, entries, nvec, affd, flags);
> + rc = msi
> From: Thomas Gleixner
> Sent: Friday, November 11, 2022 9:54 PM
>
> Enough of history and theory. Here comes part 1:
>
> This is just a cleanup and a reorganisation of the PCI/MSI code which
> became quite an unreadable mess over time. There is no intentional
> functional change in this series
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig
> Cc: k...@vger.kernel.org; Will Deacon ; linuxppc-
> d...@lists.ozlabs.org; dri-de...@lists.freedesktop.org; Li Yang
> ; io...@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph Hellwi
> From: Yongji Xie
> Sent: Wednesday, April 27, 2016 8:22 PM
>
> Current vfio-pci implementation disallows to mmap
> sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
> page may be shared with other BARs. This will cause some
> performance issues when we passthrough a PCI device with
>
> From: Yongji Xie
> Sent: Wednesday, April 27, 2016 8:43 PM
>
> This patch enables mmapping MSI-X tables if hardware supports
> interrupt remapping which can ensure that a given pci device
> can only shoot the MSIs assigned for it.
>
> With MSI-X table mmapped, we also need to expose the
> read/
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> Sent: Tuesday, May 03, 2016 1:52 PM
>
> >> +
> >> + if (!(res->start & ~PAGE_MASK)) {
> >> + /*
> >> + * Add shadow resource for sub-page bar whose mmio
> >> + * page is exclusive
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> Sent: Tuesday, May 03, 2016 2:08 PM
>
> On 2016/5/3 13:34, Tian, Kevin wrote:
>
> >> From: Yongji Xie
> >> Sent: Wednesday, April 27, 2016 8:43 PM
> >>
> >> This patch enables mmappi
> From: Yongji Xie
> Sent: Tuesday, May 03, 2016 3:34 PM
>
> On 2016/5/3 14:22, Tian, Kevin wrote:
>
> >> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> >> Sent: Tuesday, May 03, 2016 2:08 PM
> >>
> >> On 2016/5/3 13:34, Tian, Ke
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> Sent: Thursday, May 05, 2016 7:43 PM
>
> Hi David and Kevin,
>
> On 2016/5/5 17:54, David Laight wrote:
>
> > From: Tian, Kevin
> >> Sent: 05 May 2016 10:37
> > ...
> >>> Acu
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 05, 2016 11:05 PM
>
> On Thu, 5 May 2016 12:15:46 +0000
> "Tian, Kevin" wrote:
>
> > > From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
> > > Sent: Thursday, May 0
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, May 11, 2016 11:54 PM
>
> On Wed, 11 May 2016 06:29:06 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursda
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, May 12, 2016 10:21 AM
>
> On Thu, 12 May 2016 01:19:44 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:48 AM
>
> On Thu, 12 May 2016 04:53:19 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, Ma
> From: Tian, Kevin
> Sent: Friday, May 13, 2016 10:33 AM
>
> > means. The MSI-X vector table of a device is always considered
> > untrusted which is why we require user opt-ins to subvert that
> > protection. Thanks,
> >
>
> I only partially agree with
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, May 13, 2016 1:33 PM
> > >
> > > As argued previously in this thread, there's nothing special about a
> > > DMA write to memory versus a DMA write to a special address that
> > > triggers an MSI vector. If the device is DM
> From: Alexey Kardashevskiy
> Sent: Friday, July 8, 2022 2:35 PM
> On 7/8/22 15:00, Alexey Kardashevskiy wrote:
> >
> >
> > On 7/8/22 01:10, Jason Gunthorpe wrote:
> >> On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
> >>> Historically PPC64 managed to avoid using iommu_ops.
> From: Alexey Kardashevskiy
> Sent: Friday, July 8, 2022 5:46 PM
>
> >>>
> >>> In general, is "domain" something from hardware or it is a software
> >>> concept? Thanks,
> >>>
> >
> > 'domain' is a software concept to represent the hardware I/O page
> > table. A blocking domain means all DMAs fr
> From: Oliver O'Halloran
> Sent: Friday, July 29, 2022 10:53 AM
>
> On Fri, Jul 29, 2022 at 12:21 PM Alexey Kardashevskiy wrote:
> >
> > *snip*
> >
> > About this. If a platform has a concept of explicit DMA windows (2 or
> > more), is it one domain with 2 windows or 2 domains with one window
>
> From: Alexey Kardashevskiy
> Sent: Friday, July 29, 2022 11:50 AM
>
>
> On 29/07/2022 13:10, Tian, Kevin wrote:
> >> From: Oliver O'Halloran
> >> Sent: Friday, July 29, 2022 10:53 AM
> >>
> >> On Fri, Jul 29, 2022 at 1
33 matches
Mail list logo
