From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Stuart Yoder <stuyoder@gmail.com>,
rafael@kernel.org, David Airlie <airlied@linux.ie>,
linux-pci@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Diana Craciun <diana.craciun@oss.nxp.com>,
Dmitry Osipenko <digetx@gmail.com>, Will Deacon <will@kernel.org>,
Ashok Raj <ashok.raj@intel.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
Kevin Tian <kevin.tian@intel.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Dan Williams <dan.j.williams@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cornelia Huck <cohuck@redhat.com>,
linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>,
iommu@lists.linux-foundation.org,
Jacob jun Pan <jacob.jun.pan@intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v4 07/13] iommu: Add iommu_at[de]tach_device_shared() for multi-device groups
Date: Fri, 24 Dec 2021 09:30:17 +0800 [thread overview]
Message-ID: <50b8bb0f-3873-b128-48e8-22f6142f7118@linux.intel.com> (raw)
In-Reply-To: <20211223140300.GC1779224@nvidia.com>
Hi Jason,
On 12/23/21 10:03 PM, Jason Gunthorpe wrote:
>>> I think it would be clear why iommu_group_set_dma_owner(), which
>>> actually does detatch, is not the same thing as iommu_attach_device().
>> iommu_device_set_dma_owner() will eventually call
>> iommu_group_set_dma_owner(). I didn't get why
>> iommu_group_set_dma_owner() is special and need to keep.
> Not quite, they would not call each other, they have different
> implementations:
>
> int iommu_device_use_dma_api(struct device *device)
> {
> struct iommu_group *group = device->iommu_group;
>
> if (!group)
> return 0;
>
> mutex_lock(&group->mutex);
> if (group->owner_cnt != 0 ||
> group->domain != group->default_domain) {
> mutex_unlock(&group->mutex);
> return -EBUSY;
> }
> group->owner_cnt = 1;
> group->owner = NULL;
> mutex_unlock(&group->mutex);
> return 0;
> }
It seems that this function doesn't work for multi-device groups. When
the user unbinds all native drivers from devices in the group and start
to bind them with vfio-pci and assign them to user, how could iommu know
whether the group is viable for user?
>
> int iommu_group_set_dma_owner(struct iommu_group *group, struct file *owner)
> {
> mutex_lock(&group->mutex);
> if (group->owner_cnt != 0) {
> if (group->owner != owner)
> goto err_unlock;
> group->owner_cnt++;
> mutex_unlock(&group->mutex);
> return 0;
> }
> if (group->domain && group->domain != group->default_domain)
> goto err_unlock;
>
> __iommu_detach_group(group->domain, group);
> group->owner_cnt = 1;
> group->owner = owner;
> mutex_unlock(&group->mutex);
> return 0;
>
> err_unlock;
> mutex_unlock(&group->mutex);
> return -EBUSY;
> }
>
> It is the same as how we ended up putting the refcounting logic
> directly into the iommu_attach_device().
>
> See, we get rid of the enum as a multiplexor parameter, each API does
> only wnat it needs, they don't call each other.
I like the idea of removing enum parameter and make the API name
specific. But I didn't get why they can't call each other even the
data in group is the same.
>
> We don't need _USER anymore because iommu_group_set_dma_owner() always
> does detatch, and iommu_replace_group_domain() avoids ever reassigning
> default_domain. The sepecial USER behavior falls out automatically.
This means we will grow more group-centric interfaces. My understanding
is the opposite that we should hide the concept of group in IOMMU
subsystem, and the device drivers only faces device specific interfaces.
The iommu groups are created by the iommu subsystem. The device drivers
don't play any role in determining which device belongs to which group.
So the iommu interfaces for device driver shouldn't rely on the group.
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-12-24 1:30 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-17 6:36 [PATCH v4 00/13] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2021-12-17 6:36 ` [PATCH v4 01/13] iommu: Add device dma ownership set/release interfaces Lu Baolu
2021-12-17 6:36 ` [PATCH v4 02/13] driver core: Set DMA ownership during driver bind/unbind Lu Baolu
2021-12-22 12:47 ` Greg Kroah-Hartman
2021-12-22 17:52 ` Jason Gunthorpe via iommu
2021-12-23 2:08 ` Lu Baolu
2021-12-23 3:02 ` Lu Baolu
2021-12-23 7:13 ` Greg Kroah-Hartman
2021-12-23 7:23 ` Lu Baolu
2021-12-31 0:36 ` Jason Gunthorpe via iommu
2021-12-17 6:36 ` [PATCH v4 03/13] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2021-12-29 20:42 ` Bjorn Helgaas
2021-12-30 5:34 ` Lu Baolu
2021-12-30 22:24 ` Bjorn Helgaas
2021-12-31 0:40 ` Jason Gunthorpe via iommu
2021-12-31 1:10 ` Lu Baolu
2021-12-31 1:58 ` Lu Baolu
2022-01-03 19:53 ` Jason Gunthorpe via iommu
2022-01-04 1:54 ` Lu Baolu
2021-12-31 1:06 ` Lu Baolu
2021-12-17 6:36 ` [PATCH v4 04/13] PCI: portdrv: " Lu Baolu
2021-12-29 21:16 ` Bjorn Helgaas
2021-12-30 5:49 ` Lu Baolu
2021-12-17 6:37 ` [PATCH v4 05/13] iommu: Add security context management for assigned devices Lu Baolu
2021-12-17 6:37 ` [PATCH v4 06/13] iommu: Expose group variants of dma ownership interfaces Lu Baolu
2021-12-17 6:37 ` [PATCH v4 07/13] iommu: Add iommu_at[de]tach_device_shared() for multi-device groups Lu Baolu
2021-12-21 16:50 ` Robin Murphy
2021-12-21 18:46 ` Jason Gunthorpe via iommu
2021-12-22 4:22 ` Lu Baolu
2021-12-22 4:25 ` Lu Baolu
2021-12-22 20:26 ` Robin Murphy
2021-12-23 0:57 ` Jason Gunthorpe via iommu
2021-12-23 5:53 ` Lu Baolu
2021-12-23 14:03 ` Jason Gunthorpe via iommu
2021-12-24 1:30 ` Lu Baolu [this message]
2021-12-24 2:50 ` Jason Gunthorpe via iommu
2021-12-24 6:44 ` Lu Baolu
2022-01-04 1:53 ` Lu Baolu
2021-12-24 3:19 ` Lu Baolu
2021-12-24 14:24 ` Jason Gunthorpe via iommu
2021-12-17 6:37 ` [PATCH v4 08/13] vfio: Set DMA USER ownership for VFIO devices Lu Baolu
2021-12-17 6:37 ` [PATCH v4 09/13] vfio: Remove use of vfio_group_viable() Lu Baolu
2021-12-17 6:37 ` [PATCH v4 10/13] vfio: Delete the unbound_list Lu Baolu
2021-12-17 6:37 ` [PATCH v4 11/13] vfio: Remove iommu group notifier Lu Baolu
2021-12-17 6:37 ` [PATCH v4 12/13] iommu: Remove iommu group changes notifier Lu Baolu
2021-12-17 6:37 ` [PATCH v4 13/13] drm/tegra: Use the iommu dma_owner mechanism Lu Baolu
2022-01-04 5:23 ` [PATCH v4 00/13] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
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=50b8bb0f-3873-b128-48e8-22f6142f7118@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=airlied@linux.ie \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=cohuck@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=daniel@ffwll.ch \
--cc=diana.craciun@oss.nxp.com \
--cc=digetx@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=kch@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leoyang.li@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=stuyoder@gmail.com \
--cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox