Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems

Alex Williamson
2023-03-07T01:00:34Z

On Mon, 6 Mar 2023 18:35:22 -0600 (CST)
Timothy Pearson <tpearson@raptorengineering.com> wrote:

> ----- Original Message -----
> > From: "Alex Williamson" <alex.williamson@redhat.com>
> > To: "Timothy Pearson" <tpearson@raptorengineering.com>
> > Cc: "kvm" <kvm@vger.kernel.org>, "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
> > Sent: Monday, March 6, 2023 5:46:07 PM
> > Subject: Re: [PATCH v2 0/4] Reenable VFIO support on POWER systems
>
> > On Mon, 6 Mar 2023 11:29:53 -0600 (CST)
> > Timothy Pearson <tpearson@raptorengineering.com> wrote:
> >
> >> This patch series reenables VFIO support on POWER systems. It
> >> is based on Alexey Kardashevskiys's patch series, rebased and
> >> successfully tested under QEMU with a Marvell PCIe SATA controller
> >> on a POWER9 Blackbird host.
> >>
> >> Alexey Kardashevskiy (3):
> >> powerpc/iommu: Add "borrowing" iommu_table_group_ops
> >> powerpc/pci_64: Init pcibios subsys a bit later
> >> powerpc/iommu: Add iommu_ops to report capabilities and allow blocking
> >> domains
> >>
> >> Timothy Pearson (1):
> >> Add myself to MAINTAINERS for Power VFIO support
> >>
> >> MAINTAINERS | 5 +
> >> arch/powerpc/include/asm/iommu.h | 6 +-
> >> arch/powerpc/include/asm/pci-bridge.h | 7 +
> >> arch/powerpc/kernel/iommu.c | 246 +++++++++++++++++++++-
> >> arch/powerpc/kernel/pci_64.c | 2 +-
> >> arch/powerpc/platforms/powernv/pci-ioda.c | 36 +++-
> >> arch/powerpc/platforms/pseries/iommu.c | 27 +++
> >> arch/powerpc/platforms/pseries/pseries.h | 4 +
> >> arch/powerpc/platforms/pseries/setup.c | 3 +
> >> drivers/vfio/vfio_iommu_spapr_tce.c | 96 ++-------
> >> 10 files changed, 338 insertions(+), 94 deletions(-)
> >>
> >
> > For vfio and MAINTAINERS portions,
> >
> > Acked-by: Alex Williamson <alex.williamson@redhat.com>
> >
> > I'll note though that spapr_tce_take_ownership() looks like it copied a
> > bug from the old tce_iommu_take_ownership() where tbl and tbl->it_map
> > are tested before calling iommu_take_ownership() but not in the unwind
> > loop, ie. tables we might have skipped on setup are unconditionally
> > released on unwind. Thanks,
> >
> > Alex
>
> Thanks for that. I'll put together a patch to get rid of that
> potential bug that can be applied after this series is merged, unless
> you'd rather I resubmit a v3 with the issue fixed?

Follow-up fix is fine by me. Thanks,

Alex