linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] iommu/s390: tolerate repeat attach_dev calls
@ 2022-05-19 18:29 Matthew Rosato
  2022-05-19 18:30 ` Matthew Rosato
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Matthew Rosato @ 2022-05-19 18:29 UTC (permalink / raw)
  To: jgg, joro
  Cc: will, alex.williamson, cohuck, borntraeger, schnelle,
	gerald.schaefer, farman, iommu, linux-s390, kvm, linux-kernel

Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
always assign a domain") s390-iommu will get called to allocate multiple
unmanaged iommu domains for a vfio-pci device -- however the current
s390-iommu logic tolerates only one.  Recognize that multiple domains can
be allocated and handle switching between DMA or different iommu domain
tables during attach_dev.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
---
 drivers/iommu/s390-iommu.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index 3833e86c6e7b..c898bcbbce11 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@ -99,7 +99,7 @@ static int s390_iommu_attach_device(struct iommu_domain *domain,
 	if (!domain_device)
 		return -ENOMEM;
 
-	if (zdev->dma_table) {
+	if (zdev->dma_table && !zdev->s390_domain) {
 		cc = zpci_dma_exit_device(zdev);
 		if (cc) {
 			rc = -EIO;
@@ -107,6 +107,9 @@ static int s390_iommu_attach_device(struct iommu_domain *domain,
 		}
 	}
 
+	if (zdev->s390_domain)
+		zpci_unregister_ioat(zdev, 0);
+
 	zdev->dma_table = s390_domain->dma_table;
 	cc = zpci_register_ioat(zdev, 0, zdev->start_dma, zdev->end_dma,
 				virt_to_phys(zdev->dma_table));
@@ -136,7 +139,13 @@ static int s390_iommu_attach_device(struct iommu_domain *domain,
 	return 0;
 
 out_restore:
-	zpci_dma_init_device(zdev);
+	if (!zdev->s390_domain) {
+		zpci_dma_init_device(zdev);
+	} else {
+		zdev->dma_table = zdev->s390_domain->dma_table;
+		zpci_register_ioat(zdev, 0, zdev->start_dma, zdev->end_dma,
+				   virt_to_phys(zdev->dma_table));
+	}
 out_free:
 	kfree(domain_device);
 
@@ -167,7 +176,7 @@ static void s390_iommu_detach_device(struct iommu_domain *domain,
 	}
 	spin_unlock_irqrestore(&s390_domain->list_lock, flags);
 
-	if (found) {
+	if (found && (zdev->s390_domain == s390_domain)) {
 		zdev->s390_domain = NULL;
 		zpci_unregister_ioat(zdev, 0);
 		zpci_dma_init_device(zdev);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu/s390: tolerate repeat attach_dev calls
  2022-05-19 18:29 [PATCH] iommu/s390: tolerate repeat attach_dev calls Matthew Rosato
@ 2022-05-19 18:30 ` Matthew Rosato
  2022-05-19 22:58 ` Jason Gunthorpe
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Matthew Rosato @ 2022-05-19 18:30 UTC (permalink / raw)
  To: jgg, joro, alex.williamson
  Cc: will, cohuck, borntraeger, schnelle, gerald.schaefer, farman,
	iommu, linux-s390, kvm, linux-kernel

On 5/19/22 2:29 PM, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu logic tolerates only one.  Recognize that multiple domains can
> be allocated and handle switching between DMA or different iommu domain
> tables during attach_dev.
> 
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---

Tested in conjuction with

https://lore.kernel.org/kvm/0-v1-9cfc47edbcd4+13546-vfio_dma_owner_fix_jgg@nvidia.com/

Along with that patch, vfio{-pci,-ap,-ccw} on s390x for -next seem happy 
again.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu/s390: tolerate repeat attach_dev calls
  2022-05-19 18:29 [PATCH] iommu/s390: tolerate repeat attach_dev calls Matthew Rosato
  2022-05-19 18:30 ` Matthew Rosato
@ 2022-05-19 22:58 ` Jason Gunthorpe
  2022-05-20  7:57 ` Joerg Roedel
  2022-05-20 10:30 ` Niklas Schnelle
  3 siblings, 0 replies; 5+ messages in thread
From: Jason Gunthorpe @ 2022-05-19 22:58 UTC (permalink / raw)
  To: Matthew Rosato
  Cc: joro, will, alex.williamson, cohuck, borntraeger, schnelle,
	gerald.schaefer, farman, iommu, linux-s390, kvm, linux-kernel

On Thu, May 19, 2022 at 02:29:29PM -0400, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu logic tolerates only one.  Recognize that multiple domains can
> be allocated and handle switching between DMA or different iommu domain
> tables during attach_dev.
> 
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---
>  drivers/iommu/s390-iommu.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Makes senese, thanks

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

Jason

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu/s390: tolerate repeat attach_dev calls
  2022-05-19 18:29 [PATCH] iommu/s390: tolerate repeat attach_dev calls Matthew Rosato
  2022-05-19 18:30 ` Matthew Rosato
  2022-05-19 22:58 ` Jason Gunthorpe
@ 2022-05-20  7:57 ` Joerg Roedel
  2022-05-20 10:30 ` Niklas Schnelle
  3 siblings, 0 replies; 5+ messages in thread
From: Joerg Roedel @ 2022-05-20  7:57 UTC (permalink / raw)
  To: Matthew Rosato
  Cc: jgg, will, alex.williamson, cohuck, borntraeger, schnelle,
	gerald.schaefer, farman, iommu, linux-s390, kvm, linux-kernel

On Thu, May 19, 2022 at 02:29:29PM -0400, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu logic tolerates only one.  Recognize that multiple domains can
> be allocated and handle switching between DMA or different iommu domain
> tables during attach_dev.
> 
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---
>  drivers/iommu/s390-iommu.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Applied to the vfio-notifier-fix topic branch, thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] iommu/s390: tolerate repeat attach_dev calls
  2022-05-19 18:29 [PATCH] iommu/s390: tolerate repeat attach_dev calls Matthew Rosato
                   ` (2 preceding siblings ...)
  2022-05-20  7:57 ` Joerg Roedel
@ 2022-05-20 10:30 ` Niklas Schnelle
  3 siblings, 0 replies; 5+ messages in thread
From: Niklas Schnelle @ 2022-05-20 10:30 UTC (permalink / raw)
  To: Matthew Rosato, jgg, joro
  Cc: will, alex.williamson, cohuck, borntraeger, gerald.schaefer,
	farman, iommu, linux-s390, kvm, linux-kernel

On Thu, 2022-05-19 at 14:29 -0400, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu logic tolerates only one.  Recognize that multiple domains can
> be allocated and handle switching between DMA or different iommu domain
> tables during attach_dev.
> 
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---

I know it's applied already and no need to add my R-b but:

Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-05-20 10:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-19 18:29 [PATCH] iommu/s390: tolerate repeat attach_dev calls Matthew Rosato
2022-05-19 18:30 ` Matthew Rosato
2022-05-19 22:58 ` Jason Gunthorpe
2022-05-20  7:57 ` Joerg Roedel
2022-05-20 10:30 ` Niklas Schnelle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).