From: Jason Gunthorpe <jgg@ziepe.ca>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: kvm@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <jroedel@suse.de>,
Alex Williamson <alex.williamson@redhat.com>,
kvm-ppc@vger.kernel.org
Subject: Re: [RFC PATCH kernel] vfio: Skip checking for IOMMU_CAP_CACHE_COHERENCY on POWER and more
Date: Sat, 2 Jul 2022 21:26:06 -0300 [thread overview]
Message-ID: <20220703002606.GZ23621@ziepe.ca> (raw)
In-Reply-To: <20220701061751.1955857-1-aik@ozlabs.ru>
On Fri, Jul 01, 2022 at 04:17:51PM +1000, Alexey Kardashevskiy wrote:
> VFIO on POWER does not implement iommu_ops and therefore iommu_capable()
> always returns false and __iommu_group_alloc_blocking_domain() always
> fails.
>
> iommu_group_claim_dma_owner() in setting container fails for the same
> reason - it cannot allocate a domain.
>
> This skips the check for platforms supporting VFIO without implementing
> iommu_ops which to my best knowledge is POWER only.
>
> This also allows setting container in absence of iommu_ops.
>
> Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
> Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Not quite sure what the proper small fix is and implementing iommu_ops
> on POWER is not going to happen any time soon or ever :-/
>
> ---
> drivers/vfio/vfio.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 61e71c1154be..71408ab26cd0 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -605,7 +605,8 @@ int vfio_register_group_dev(struct vfio_device *device)
> * VFIO always sets IOMMU_CACHE because we offer no way for userspace to
> * restore cache coherency.
> */
> - if (!iommu_capable(device->dev->bus, IOMMU_CAP_CACHE_COHERENCY))
> + if (device->dev->bus->iommu_ops &&
> + !iommu_capable(device->dev->bus, IOMMU_CAP_CACHE_COHERENCY))
> return -EINVAL;
This change should be guarded by some
IS_ENABLED(CONFIG_VFIO_IOMMU_SPAPR_TCE)
We want to do the this check here on every other
configuration. Rejecting null iommu_ops is actually a desired side
effect.
> return __vfio_register_dev(device,
> @@ -934,7 +935,7 @@ static void __vfio_group_unset_container(struct vfio_group *group)
> driver->ops->detach_group(container->iommu_data,
> group->iommu_group);
>
> - if (group->type == VFIO_IOMMU)
> + if (group->type == VFIO_IOMMU && iommu_group_dma_owner_claimed(group->iommu_group))
> iommu_group_release_dma_owner(group->iommu_group);
>
> group->container = NULL;
> @@ -1010,9 +1011,8 @@ static int vfio_group_set_container(struct vfio_group *group, int container_fd)
> }
>
> if (group->type == VFIO_IOMMU) {
> - ret = iommu_group_claim_dma_owner(group->iommu_group, f.file);
> - if (ret)
> - goto unlock_out;
> + if (iommu_group_claim_dma_owner(group->iommu_group, f.file))
> + pr_warn("Failed to claim DMA owner");
We certainly cannot ignore this. As my other email you should make
this succeed inside the iommu subsystem even though the ops are null.
Thanks,
Jason
prev parent reply other threads:[~2022-07-03 0:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 6:17 [RFC PATCH kernel] vfio: Skip checking for IOMMU_CAP_CACHE_COHERENCY on POWER and more Alexey Kardashevskiy
2022-07-01 7:10 ` Tian, Kevin
2022-07-05 0:49 ` Jason Gunthorpe
2022-07-07 1:06 ` Tian, Kevin
2022-07-01 10:34 ` Robin Murphy
2022-07-01 23:40 ` Tian, Kevin
2022-07-03 0:22 ` Jason Gunthorpe
2022-07-03 0:26 ` Jason Gunthorpe [this message]
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=20220703002606.GZ23621@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox