From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: "Jörg Rödel" <joro@8bytes.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"rafael@kernel.org" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cornelia Huck <cohuck@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Will Deacon <will@kernel.org>,
Diana Craciun <diana.craciun@oss.nxp.com>
Subject: Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces
Date: Fri, 19 Nov 2021 11:43:14 -0400 [thread overview]
Message-ID: <20211119154314.GA2105516@nvidia.com> (raw)
In-Reply-To: <20211119150612.jhsvsbzisvux2lga@8bytes.org>
On Fri, Nov 19, 2021 at 04:06:12PM +0100, Jörg Rödel wrote:
> This change came to be because the iommu_attach/detach_device()
> interface doesn't fit well into a world with iommu-groups. Devices
> within a group are by definition not isolated between each other, so
> they must all be in the same address space (== iommu_domain). So it
> doesn't make sense to allow attaching a single device within a group to
> a different iommu_domain.
It is the same problem VFIO has. It changes the iommu_domain of a
group while it only has a single driver bound to one device in the
group.
Robin is also right to point out there is no guarentee that a single
device group will remain a single device group after a hot plug
event. This is something VFIO is also able to handle today.
So, I think the solution of this series applies equally well to this
problem. Let's see it in v2.
> I know that in theory it is safe to allow devices within a group to be
> in different domains because there iommu-groups catch multiple
> non-isolation cases:
>
> 1) Devices behind a non-ACS capable bridge or multiple functions
> of a PCI device. Here it is safe to put the devices into
> different iommu-domains as long as all affected devices are
> controlled by the same owner.
>
> 2) Devices which share a single request-id and can't be
> differentiated by the IOMMU hardware. These always need to be
> in the same iommu_domain.
> To lift the single-domain-per-group requirement the iommu core code
> needs to learn the difference between the two cases above.
We had a long talk about this a while back, nobody came with
compelling arguments to justify doing this work. I've just been using
it as a guidepost for building APIs. If the API can accomodate #1 then
it is a better design than one that cannot.
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Jörg Rödel" <joro@8bytes.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"rafael@kernel.org" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cornelia Huck <cohuck@redhat.com>, Will Deacon <will@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Alex Williamson <alex.williamson@redhat.com>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Diana Craciun <diana.craciun@oss.nxp.com>
Subject: Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces
Date: Fri, 19 Nov 2021 11:43:14 -0400 [thread overview]
Message-ID: <20211119154314.GA2105516@nvidia.com> (raw)
In-Reply-To: <20211119150612.jhsvsbzisvux2lga@8bytes.org>
On Fri, Nov 19, 2021 at 04:06:12PM +0100, Jörg Rödel wrote:
> This change came to be because the iommu_attach/detach_device()
> interface doesn't fit well into a world with iommu-groups. Devices
> within a group are by definition not isolated between each other, so
> they must all be in the same address space (== iommu_domain). So it
> doesn't make sense to allow attaching a single device within a group to
> a different iommu_domain.
It is the same problem VFIO has. It changes the iommu_domain of a
group while it only has a single driver bound to one device in the
group.
Robin is also right to point out there is no guarentee that a single
device group will remain a single device group after a hot plug
event. This is something VFIO is also able to handle today.
So, I think the solution of this series applies equally well to this
problem. Let's see it in v2.
> I know that in theory it is safe to allow devices within a group to be
> in different domains because there iommu-groups catch multiple
> non-isolation cases:
>
> 1) Devices behind a non-ACS capable bridge or multiple functions
> of a PCI device. Here it is safe to put the devices into
> different iommu-domains as long as all affected devices are
> controlled by the same owner.
>
> 2) Devices which share a single request-id and can't be
> differentiated by the IOMMU hardware. These always need to be
> in the same iommu_domain.
> To lift the single-domain-per-group requirement the iommu core code
> needs to learn the difference between the two cases above.
We had a long talk about this a while back, nobody came with
compelling arguments to justify doing this work. I've just been using
it as a guidepost for building APIs. If the API can accomodate #1 then
it is a better design than one that cannot.
Jason
next prev parent reply other threads:[~2021-11-19 15:43 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 2:05 [PATCH 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 01/11] iommu: Add device dma ownership set/release interfaces Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 13:14 ` Christoph Hellwig
2021-11-15 13:14 ` Christoph Hellwig
2021-11-16 1:57 ` Lu Baolu
2021-11-16 1:57 ` Lu Baolu
2021-11-16 13:46 ` Jason Gunthorpe via iommu
2021-11-16 13:46 ` Jason Gunthorpe
2021-11-17 5:22 ` Lu Baolu
2021-11-17 5:22 ` Lu Baolu
2021-11-17 13:35 ` Jason Gunthorpe via iommu
2021-11-17 13:35 ` Jason Gunthorpe
2021-11-18 1:12 ` Lu Baolu
2021-11-18 1:12 ` Lu Baolu
2021-11-18 14:10 ` Jason Gunthorpe via iommu
2021-11-18 14:10 ` Jason Gunthorpe
2021-11-18 2:39 ` Tian, Kevin
2021-11-18 2:39 ` Tian, Kevin
2021-11-18 13:33 ` Jason Gunthorpe via iommu
2021-11-18 13:33 ` Jason Gunthorpe
2021-11-19 5:44 ` Tian, Kevin
2021-11-19 5:44 ` Tian, Kevin
2021-11-19 11:14 ` Lu Baolu
2021-11-19 11:14 ` Lu Baolu
2021-11-19 15:06 ` Jörg Rödel
2021-11-19 15:06 ` Jörg Rödel
2021-11-19 15:43 ` Jason Gunthorpe via iommu [this message]
2021-11-19 15:43 ` Jason Gunthorpe
2021-11-20 11:16 ` Lu Baolu
2021-11-20 11:16 ` Lu Baolu
2021-11-19 12:56 ` Jason Gunthorpe via iommu
2021-11-19 12:56 ` Jason Gunthorpe
2021-11-15 20:38 ` Bjorn Helgaas
2021-11-15 20:38 ` Bjorn Helgaas
2021-11-16 1:52 ` Lu Baolu
2021-11-16 1:52 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 6:59 ` Greg Kroah-Hartman
2021-11-15 6:59 ` Greg Kroah-Hartman
2021-11-15 13:20 ` Christoph Hellwig
2021-11-15 13:20 ` Christoph Hellwig
2021-11-15 13:38 ` Jason Gunthorpe via iommu
2021-11-15 13:38 ` Jason Gunthorpe
2021-11-15 13:19 ` Christoph Hellwig
2021-11-15 13:19 ` Christoph Hellwig
2021-11-15 13:24 ` Jason Gunthorpe via iommu
2021-11-15 13:24 ` Jason Gunthorpe
2021-11-15 15:37 ` Robin Murphy
2021-11-15 15:37 ` Robin Murphy
2021-11-15 15:56 ` Jason Gunthorpe via iommu
2021-11-15 15:56 ` Jason Gunthorpe
2021-11-15 18:15 ` Christoph Hellwig
2021-11-15 18:15 ` Christoph Hellwig
2021-11-15 18:35 ` Robin Murphy
2021-11-15 18:35 ` Robin Murphy
2021-11-15 19:39 ` Jason Gunthorpe via iommu
2021-11-15 19:39 ` Jason Gunthorpe
2021-11-15 2:05 ` [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 13:21 ` Christoph Hellwig
2021-11-15 13:21 ` Christoph Hellwig
2021-11-15 13:31 ` Jason Gunthorpe via iommu
2021-11-15 13:31 ` Jason Gunthorpe
2021-11-15 15:14 ` Robin Murphy
2021-11-15 15:14 ` Robin Murphy
2021-11-15 16:17 ` Jason Gunthorpe via iommu
2021-11-15 16:17 ` Jason Gunthorpe
2021-11-15 17:54 ` Robin Murphy
2021-11-15 17:54 ` Robin Murphy
2021-11-15 18:19 ` Christoph Hellwig
2021-11-15 18:19 ` Christoph Hellwig
2021-11-15 18:44 ` Robin Murphy
2021-11-15 18:44 ` Robin Murphy
2021-11-15 19:22 ` Jason Gunthorpe via iommu
2021-11-15 19:22 ` Jason Gunthorpe
2021-11-15 20:58 ` Robin Murphy
2021-11-15 20:58 ` Robin Murphy
2021-11-15 21:19 ` Jason Gunthorpe via iommu
2021-11-15 21:19 ` Jason Gunthorpe
2021-11-15 20:48 ` Bjorn Helgaas
2021-11-15 20:48 ` Bjorn Helgaas
2021-11-15 22:17 ` Bjorn Helgaas
2021-11-15 22:17 ` Bjorn Helgaas
2021-11-16 6:05 ` Lu Baolu
2021-11-16 6:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 04/11] PCI: portdrv: " Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 20:44 ` Bjorn Helgaas
2021-11-15 20:44 ` Bjorn Helgaas
2021-11-16 7:24 ` Lu Baolu
2021-11-16 7:24 ` Lu Baolu
2021-11-16 20:22 ` Bjorn Helgaas
2021-11-16 20:22 ` Bjorn Helgaas
2021-11-16 20:48 ` Jason Gunthorpe via iommu
2021-11-16 20:48 ` Jason Gunthorpe
2021-11-15 2:05 ` [PATCH 05/11] iommu: Add security context management for assigned devices Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 13:22 ` Christoph Hellwig
2021-11-15 13:22 ` Christoph Hellwig
2021-11-16 7:25 ` Lu Baolu
2021-11-16 7:25 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 06/11] iommu: Expose group variants of dma ownership interfaces Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 13:27 ` Christoph Hellwig
2021-11-15 13:27 ` Christoph Hellwig
2021-11-16 9:42 ` Lu Baolu
2021-11-16 9:42 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 07/11] vfio: Use DMA_OWNER_USER to declaim passthrough devices Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 09/11] vfio: Delete the unbound_list Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 10/11] vfio: Remove iommu group notifier Lu Baolu
2021-11-15 2:05 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 11/11] iommu: Remove iommu group changes notifier Lu Baolu
2021-11-15 2:05 ` 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=20211119154314.GA2105516@nvidia.com \
--to=iommu@lists.linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=cohuck@redhat.com \
--cc=diana.craciun@oss.nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kch@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael@kernel.org \
--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.