From: Jason Gunthorpe <jgg@nvidia.com>
To: Joerg Roedel <joro@8bytes.org>, Li Yang <leoyang.li@nxp.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
iommu@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl
Date: Sun, 28 May 2023 21:46:06 -0300 [thread overview]
Message-ID: <ZHP1zv48iZUV5Ypj@nvidia.com> (raw)
In-Reply-To: <ZGxcmJ3vH0Smqqxu@8bytes.org>
On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
> > With POWER SPAPR now having a real iommu driver and using the normal group
> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a
> > user for the iommu_group_add/remove_device() calls. This will help
> > simplify the understanding of what the core code should be doing for these
> > functions.
> >
> > Fix FSL to not need to call iommu_group_remove_device() at all.
> >
> > v2:
> > - Change the approach to use driver_managed_dma
> > - Really simplify fsl_pamu_device_group() and just put everything in one
> > function
> > - New patch to make missing OF properties a probe failure
> > v1: https://lore.kernel.org/r/0-v1-1421774b874b+167-ppc_device_group_jgg@nvidia.com
> >
> > Jason Gunthorpe (3):
> > iommu/fsl: Always allocate a group for non-pci devices
> > iommu/fsl: Move ENODEV to fsl_pamu_probe_device()
> > iommu/fsl: Use driver_managed_dma to allow VFIO to work
> >
> > arch/powerpc/sysdev/fsl_pci.c | 1 +
> > drivers/iommu/fsl_pamu_domain.c | 123 +++++++++-----------------------
> > 2 files changed, 36 insertions(+), 88 deletions(-)
>
> Any chance someone can test this on real hardware?
There isn't even a MAINTAINERS entry for this, and the git log looks
pretty dead for a long time. I tried to cc people who might care,
but I'm not so optimistic - unless Li says something.
I do feel good that if there is a problem and someone does come
forward it can be fixed up without a big trouble. Certainly without
going back to mis-using iommu_grou_add/remove_device..
Thanks,
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Joerg Roedel <joro@8bytes.org>, Li Yang <leoyang.li@nxp.com>
Cc: Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Nicholas Piggin <npiggin@gmail.com>,
iommu@lists.linux.dev, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl
Date: Sun, 28 May 2023 21:46:06 -0300 [thread overview]
Message-ID: <ZHP1zv48iZUV5Ypj@nvidia.com> (raw)
In-Reply-To: <ZGxcmJ3vH0Smqqxu@8bytes.org>
On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
> > With POWER SPAPR now having a real iommu driver and using the normal group
> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a
> > user for the iommu_group_add/remove_device() calls. This will help
> > simplify the understanding of what the core code should be doing for these
> > functions.
> >
> > Fix FSL to not need to call iommu_group_remove_device() at all.
> >
> > v2:
> > - Change the approach to use driver_managed_dma
> > - Really simplify fsl_pamu_device_group() and just put everything in one
> > function
> > - New patch to make missing OF properties a probe failure
> > v1: https://lore.kernel.org/r/0-v1-1421774b874b+167-ppc_device_group_jgg@nvidia.com
> >
> > Jason Gunthorpe (3):
> > iommu/fsl: Always allocate a group for non-pci devices
> > iommu/fsl: Move ENODEV to fsl_pamu_probe_device()
> > iommu/fsl: Use driver_managed_dma to allow VFIO to work
> >
> > arch/powerpc/sysdev/fsl_pci.c | 1 +
> > drivers/iommu/fsl_pamu_domain.c | 123 +++++++++-----------------------
> > 2 files changed, 36 insertions(+), 88 deletions(-)
>
> Any chance someone can test this on real hardware?
There isn't even a MAINTAINERS entry for this, and the git log looks
pretty dead for a long time. I tried to cc people who might care,
but I'm not so optimistic - unless Li says something.
I do feel good that if there is a problem and someone does come
forward it can be fixed up without a big trouble. Certainly without
going back to mis-using iommu_grou_add/remove_device..
Thanks,
Jason
next prev parent reply other threads:[~2023-05-29 0:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 0:35 [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl Jason Gunthorpe
2023-05-17 0:35 ` [PATCH v2 1/3] iommu/fsl: Always allocate a group for non-pci devices Jason Gunthorpe
2023-05-17 0:35 ` [PATCH v2 2/3] iommu/fsl: Move ENODEV to fsl_pamu_probe_device() Jason Gunthorpe
2023-05-17 0:35 ` [PATCH v2 3/3] iommu/fsl: Use driver_managed_dma to allow VFIO to work Jason Gunthorpe
2023-05-23 6:26 ` [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl Joerg Roedel
2023-05-23 6:26 ` Joerg Roedel
2023-05-29 0:46 ` Jason Gunthorpe [this message]
2023-05-29 0:46 ` Jason Gunthorpe
2023-05-30 12:03 ` Michael Ellerman
2023-05-30 12:03 ` Michael Ellerman
2023-05-30 13:43 ` Jason Gunthorpe
2023-05-30 13:43 ` Jason Gunthorpe
2023-05-31 7:04 ` Michael Ellerman
2023-05-31 7:04 ` Michael Ellerman
2023-06-01 9:48 ` Joerg Roedel
2023-06-01 9:48 ` Joerg Roedel
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=ZHP1zv48iZUV5Ypj@nvidia.com \
--to=jgg@nvidia.com \
--cc=christophe.leroy@csgroup.eu \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=leoyang.li@nxp.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=robin.murphy@arm.com \
--cc=will@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 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.