From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Alex Williamson <alex.williamson@redhat.com>,
Thierry Reding <thierry.reding@gmail.com>,
Ben Skeggs <bskeggs@redhat.com>, Daniel Vetter <daniel@ffwll.ch>,
Jonathan Hunter <jonathanh@nvidia.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH 0/7] iommu cleanup and refactoring
Date: Tue, 25 Jan 2022 11:16:02 -0400 [thread overview]
Message-ID: <20220125151602.GL84788@nvidia.com> (raw)
In-Reply-To: <7febcba4-f5bf-6bf6-6180-895b18d1b806@arm.com>
On Tue, Jan 25, 2022 at 02:48:02PM +0000, Robin Murphy wrote:
> Agreed, certainly an IOMMU_DOMAIN_SVA type that can both encapsulate the mm
> and effectively replace iommu_sva seems like a logical and fairly small next
> step. We already have the paradigm of different domain types supporting
> different ops, so initially an SVA domain would simply allow bind/unbind
> rather than attach/detach/map/unmap.
I hope we can quickly get to a PASID enabled generic attach/detach
scheme - we really need this to do the uAPI part of this interface.
> they are fundamentally different things in their own right, and the ideal
> API should give us the orthogonality to also bind a device to an SVA domain
> without PASID (e.g. for KVM stage 2, or userspace assignment of simpler
> fault/stall-tolerant devices), or attach PASIDs to regular iommu_domains.
Yes, these are orthogonal things. A iommu driver that supports PASID
ideally should support PASID enabled attach/detatch for every
iommu_domain type it supports.
SVA should not be entangled with PASID beyond that SVA is often used
with PASID - a SVA iommu_domain should be fully usable with a RID too.
I'm hoping to see the core iommu code provide some simplified "SVA"
API that under the covers creates a SVA domain and then does a normal
PASID attach using the global PASID in the mm_struct - the
driver should not care what, or even if, PASID is used for a SVA
domain.
Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-01-25 15:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 7:10 [PATCH 0/7] iommu cleanup and refactoring Lu Baolu
2022-01-24 7:10 ` [PATCH 1/7] iommu/vt-d: Remove guest pasid related callbacks Lu Baolu
2022-01-24 9:25 ` Christoph Hellwig
2022-01-24 7:10 ` [PATCH 2/7] iommu: Remove guest pasid related interfaces and definitions Lu Baolu
2022-01-24 9:26 ` Christoph Hellwig
2022-01-24 7:10 ` [PATCH 3/7] iommu/vt-d: Remove aux-domain related callbacks Lu Baolu
2022-01-24 9:26 ` Christoph Hellwig
2022-01-24 7:10 ` [PATCH 4/7] iommu: Remove aux-domain related interfaces and iommu_ops Lu Baolu
2022-01-24 9:27 ` Christoph Hellwig
2022-01-24 7:11 ` [PATCH 5/7] drm/nouveau/device: Get right pgsize_bitmap of iommu_domain Lu Baolu
2022-01-24 9:29 ` Christoph Hellwig
2022-01-25 2:59 ` Lu Baolu
2022-01-24 7:11 ` [PATCH 6/7] iommu: Use right way to retrieve iommu_ops Lu Baolu
2022-01-24 9:32 ` Christoph Hellwig
2022-01-25 3:01 ` Lu Baolu
2022-01-24 9:48 ` Tian, Kevin
2022-01-25 3:04 ` Lu Baolu
2022-01-24 17:36 ` Jason Gunthorpe via iommu
2022-01-25 3:18 ` Lu Baolu
2022-01-25 0:20 ` Robin Murphy
2022-01-25 3:54 ` Lu Baolu
2022-01-24 7:11 ` [PATCH 7/7] iommu: Add iommu_domain::domain_ops Lu Baolu
2022-01-24 9:37 ` Christoph Hellwig
2022-01-24 17:24 ` Jason Gunthorpe via iommu
2022-01-25 4:43 ` Lu Baolu
2022-01-25 4:42 ` Lu Baolu
2022-01-24 9:58 ` Tian, Kevin
2022-01-24 10:16 ` Jean-Philippe Brucker
2022-01-24 16:33 ` Jason Gunthorpe via iommu
2022-01-26 9:41 ` Jean-Philippe Brucker
2022-01-24 17:17 ` Jason Gunthorpe via iommu
2022-01-25 4:59 ` Lu Baolu
2022-01-25 12:37 ` Jason Gunthorpe via iommu
2022-01-24 17:55 ` Jason Gunthorpe via iommu
2022-01-25 5:04 ` Lu Baolu
2022-01-25 0:57 ` Robin Murphy
2022-01-25 6:27 ` Lu Baolu
2022-01-25 14:23 ` Robin Murphy
2022-01-25 15:00 ` Jason Gunthorpe via iommu
2022-01-24 9:46 ` [PATCH 0/7] iommu cleanup and refactoring Tian, Kevin
2022-01-24 17:44 ` Jason Gunthorpe via iommu
2022-01-25 1:11 ` Tian, Kevin
2022-01-25 14:48 ` Robin Murphy
2022-01-25 15:16 ` Jason Gunthorpe via iommu [this message]
2022-01-26 1:51 ` Lu Baolu
2022-01-26 13:27 ` Jason Gunthorpe via iommu
2022-01-26 14:00 ` Robin Murphy
2022-02-08 1:32 ` 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=20220125151602.GL84788@nvidia.com \
--to=iommu@lists.linux-foundation.org \
--cc=airlied@linux.ie \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bskeggs@redhat.com \
--cc=daniel@ffwll.ch \
--cc=hch@infradead.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.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 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.