From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Eric Farman <farman@linux.ibm.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <jroedel@suse.de>,
Robin Murphy <robin.murphy@arm.com>,
Qian Cai <quic_qiancai@quicinc.com>,
iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v3] iommu: iommu_group_claim_dma_owner() must always assign a domain
Date: Wed, 18 May 2022 16:14:46 -0300 [thread overview]
Message-ID: <20220518191446.GU1343366@nvidia.com> (raw)
In-Reply-To: <183e155eae268c32e7d02f68846250702fe99065.camel@linux.ibm.com>
On Wed, May 18, 2022 at 02:50:36PM -0400, Eric Farman wrote:
> I got a heads up from Matt about the s390 KVM vfio- variants failing on
> linux-next.
>
> For vfio-ap and vfio-ccw, they fail on the above error. Both calls to
> __iommu_domain_alloc fail because while dev->dev->bus is non-NULL (it
> points to the mdev bus_type registered in mdev_init()), the bus-
> >iommu_ops pointer is NULL. Which makes sense; the iommu_group is vfio-
> noiommu, via vfio_register_emulated_iommu_dev(), and mdev didn't
> establish an iommu_ops for its bus.
Oh, I think this is a VFIO problem, the iommu layer should not have to
deal with these fake non-iommu groups.
From 9884850a5ceac957e6715beab0888294d4088877 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg@nvidia.com>
Date: Wed, 18 May 2022 16:03:34 -0300
Subject: [PATCH] vfio: Do not manipulate iommu dma_owner for fake iommu groups
Since asserting dma ownership now causes the group to have its DMA blocked
the iommu layer requires a working iommu. This means the dma_owner APIs
cannot be used on the fake groups that VFIO creates. Test for this and
avoid calling them.
Otherwise asserting dma ownership will fail for VFIO mdev devices as a
BLOCKING iommu_domain cannot be allocated due to the NULL iommu ops.
Fixes: 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must always assign a domain")
Reported-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/vfio/vfio.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
I think this will have to go through Alex's tree due to all the other rework
in this area.
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index cfcff7764403fc..f5ed03897210c3 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -927,7 +927,8 @@ static void __vfio_group_unset_container(struct vfio_group *group)
driver->ops->detach_group(container->iommu_data,
group->iommu_group);
- iommu_group_release_dma_owner(group->iommu_group);
+ if (group->type == VFIO_IOMMU)
+ iommu_group_release_dma_owner(group->iommu_group);
group->container = NULL;
group->container_users = 0;
@@ -1001,9 +1002,11 @@ static int vfio_group_set_container(struct vfio_group *group, int container_fd)
goto unlock_out;
}
- ret = iommu_group_claim_dma_owner(group->iommu_group, f.file);
- if (ret)
- goto unlock_out;
+ if (group->type == VFIO_IOMMU) {
+ ret = iommu_group_claim_dma_owner(group->iommu_group, f.file);
+ if (ret)
+ goto unlock_out;
+ }
driver = container->iommu_driver;
if (driver) {
@@ -1011,7 +1014,9 @@ static int vfio_group_set_container(struct vfio_group *group, int container_fd)
group->iommu_group,
group->type);
if (ret) {
- iommu_group_release_dma_owner(group->iommu_group);
+ if (group->type == VFIO_IOMMU)
+ iommu_group_release_dma_owner(
+ group->iommu_group);
goto unlock_out;
}
}
--
2.36.0
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-05-18 19:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 16:19 [PATCH v3] iommu: iommu_group_claim_dma_owner() must always assign a domain Jason Gunthorpe via iommu
2022-05-09 22:15 ` Robin Murphy
2022-05-10 0:56 ` Tian, Kevin
2022-05-13 12:54 ` Joerg Roedel
2022-05-18 18:50 ` Eric Farman
2022-05-18 19:14 ` Jason Gunthorpe via iommu [this message]
2022-05-18 19:32 ` Eric Farman
2022-05-19 7:32 ` Joerg Roedel
2022-05-19 16:51 ` Alex Williamson
2022-05-19 16:53 ` Jason Gunthorpe via iommu
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=20220518191446.GU1343366@nvidia.com \
--to=iommu@lists.linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jgg@nvidia.com \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=quic_qiancai@quicinc.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.