All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	Nicholas Piggin <npiggin@gmail.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Frederic Barrat <fbarrat@linux.ibm.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm-ppc@vger.kernel.org, Deming Wang <wangdeming@inspur.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	Fabiano Rosas <farosas@linux.ibm.com>,
	Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Subject: Re: [PATCH kernel v2 3/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking dom
Date: Tue, 20 Sep 2022 13:43:16 +0000	[thread overview]
Message-ID: <YynDdJRr6fCBCm7Z@nvidia.com> (raw)
In-Reply-To: <20220920130457.29742-4-aik@ozlabs.ru>

On Tue, Sep 20, 2022 at 11:04:57PM +1000, Alexey Kardashevskiy wrote:
> Up until now PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development added 2 uses of iommu_ops to
> the generic VFIO which broke POWER:
> - a coherency capability check;
> - blocking IOMMU domain - iommu_group_dma_owner_claimed()/...
> 
> This adds a simple iommu_ops which reports support for cache
> coherency and provides a basic support for blocking domains. No other
> domain types are implemented so the default domain is NULL.
> 
> Since now iommu_ops controls the group ownership, this takes it out of
> VFIO.
> 
> This adds an IOMMU device into a pci_controller (=PHB) and registers it
> in the IOMMU subsystem, iommu_ops is registered at this point.
> This setup is done in postcore_initcall_sync.
> 
> This replaces iommu_group_add_device() with iommu_probe_device() as
> the former misses necessary steps in connecting PCI devices to IOMMU
> devices. This adds a comment about why explicit iommu_probe_device()
> is still needed.
> 
> Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
> Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
> Cc: Deming Wang <wangdeming@inspur.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Daniel Henrique Barboza <danielhb413@gmail.com>
> Cc: Fabiano Rosas <farosas@linux.ibm.com>
> Cc: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * replaced a default domain with blocked

Code wise this is much better..

But it is a bit unsettling to see the blocked domain co-opted to mean
'some platform specific VFIO behavior' - don't have a better idea for
this series though.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: kvm@vger.kernel.org, Fabiano Rosas <farosas@linux.ibm.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	Deming Wang <wangdeming@inspur.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm-ppc@vger.kernel.org,
	Murilo Opsfelder Araujo <muriloo@linux.ibm.com>,
	Frederic Barrat <fbarrat@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH kernel v2 3/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains
Date: Tue, 20 Sep 2022 10:43:16 -0300	[thread overview]
Message-ID: <YynDdJRr6fCBCm7Z@nvidia.com> (raw)
In-Reply-To: <20220920130457.29742-4-aik@ozlabs.ru>

On Tue, Sep 20, 2022 at 11:04:57PM +1000, Alexey Kardashevskiy wrote:
> Up until now PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development added 2 uses of iommu_ops to
> the generic VFIO which broke POWER:
> - a coherency capability check;
> - blocking IOMMU domain - iommu_group_dma_owner_claimed()/...
> 
> This adds a simple iommu_ops which reports support for cache
> coherency and provides a basic support for blocking domains. No other
> domain types are implemented so the default domain is NULL.
> 
> Since now iommu_ops controls the group ownership, this takes it out of
> VFIO.
> 
> This adds an IOMMU device into a pci_controller (=PHB) and registers it
> in the IOMMU subsystem, iommu_ops is registered at this point.
> This setup is done in postcore_initcall_sync.
> 
> This replaces iommu_group_add_device() with iommu_probe_device() as
> the former misses necessary steps in connecting PCI devices to IOMMU
> devices. This adds a comment about why explicit iommu_probe_device()
> is still needed.
> 
> Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
> Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
> Cc: Deming Wang <wangdeming@inspur.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Daniel Henrique Barboza <danielhb413@gmail.com>
> Cc: Fabiano Rosas <farosas@linux.ibm.com>
> Cc: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * replaced a default domain with blocked

Code wise this is much better..

But it is a bit unsettling to see the blocked domain co-opted to mean
'some platform specific VFIO behavior' - don't have a better idea for
this series though.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	Nicholas Piggin <npiggin@gmail.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Frederic Barrat <fbarrat@linux.ibm.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm-ppc@vger.kernel.org, Deming Wang <wangdeming@inspur.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	Fabiano Rosas <farosas@linux.ibm.com>,
	Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Subject: Re: [PATCH kernel v2 3/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains
Date: Tue, 20 Sep 2022 10:43:16 -0300	[thread overview]
Message-ID: <YynDdJRr6fCBCm7Z@nvidia.com> (raw)
In-Reply-To: <20220920130457.29742-4-aik@ozlabs.ru>

On Tue, Sep 20, 2022 at 11:04:57PM +1000, Alexey Kardashevskiy wrote:
> Up until now PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development added 2 uses of iommu_ops to
> the generic VFIO which broke POWER:
> - a coherency capability check;
> - blocking IOMMU domain - iommu_group_dma_owner_claimed()/...
> 
> This adds a simple iommu_ops which reports support for cache
> coherency and provides a basic support for blocking domains. No other
> domain types are implemented so the default domain is NULL.
> 
> Since now iommu_ops controls the group ownership, this takes it out of
> VFIO.
> 
> This adds an IOMMU device into a pci_controller (=PHB) and registers it
> in the IOMMU subsystem, iommu_ops is registered at this point.
> This setup is done in postcore_initcall_sync.
> 
> This replaces iommu_group_add_device() with iommu_probe_device() as
> the former misses necessary steps in connecting PCI devices to IOMMU
> devices. This adds a comment about why explicit iommu_probe_device()
> is still needed.
> 
> Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
> Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
> Cc: Deming Wang <wangdeming@inspur.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Daniel Henrique Barboza <danielhb413@gmail.com>
> Cc: Fabiano Rosas <farosas@linux.ibm.com>
> Cc: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v2:
> * replaced a default domain with blocked

Code wise this is much better..

But it is a bit unsettling to see the blocked domain co-opted to mean
'some platform specific VFIO behavior' - don't have a better idea for
this series though.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

  reply	other threads:[~2022-09-20 13:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 13:04 [PATCH kernel v2 0/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains Alexey Kardashevskiy
2022-09-20 13:04 ` Alexey Kardashevskiy
2022-09-20 13:04 ` Alexey Kardashevskiy
2022-09-20 13:04 ` [PATCH kernel v2 1/3] powerpc/iommu: Add "borrowing" iommu_table_group_ops Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:04 ` [PATCH kernel v2 2/3] powerpc/pci_64: Init pcibios subsys a bit later Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:04 ` [PATCH kernel v2 3/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:04   ` Alexey Kardashevskiy
2022-09-20 13:43   ` Jason Gunthorpe [this message]
2022-09-20 13:43     ` Jason Gunthorpe
2022-09-20 13:43     ` Jason Gunthorpe
2022-10-27  7:39 ` [PATCH kernel v2 0/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking dom Alexey Kardashevskiy
2022-10-27  7:39   ` [PATCH kernel v2 0/3] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains Alexey Kardashevskiy
2022-10-27  7:39   ` Alexey Kardashevskiy

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=YynDdJRr6fCBCm7Z@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=danielhb413@gmail.com \
    --cc=farosas@linux.ibm.com \
    --cc=fbarrat@linux.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=muriloo@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=wangdeming@inspur.com \
    /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.