From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
Ashok Raj <ashok.raj@intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
iommu@lists.linux-foundation.org,
Jacob jun Pan <jacob.jun.pan@intel.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH 2/5] iommu: Add blocking_domain_ops field in iommu_ops
Date: Tue, 17 May 2022 10:13:24 -0300 [thread overview]
Message-ID: <20220517131324.GU1343366@nvidia.com> (raw)
In-Reply-To: <f971aea9-8ae1-95f8-b10a-cd77e9704dc0@arm.com>
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
> FWIW from my point of view I'm happy with having a .detach_dev_pasid op
> meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please. 'set_dev_pasid' and 'set_dev_blocking_pasid' are clearer
names.
> On SMMUv3, PASIDs don't mix with our current notion of
> IOMMU_DOMAIN_IDENTITY (nor the potential one for
> IOMMU_DOMAIN_BLOCKED), so giving PASIDs functional symmetry with
> devices would need significantly more work anyway.
There is no extra work in the driver, beyond SMMU having to implement
a blocking domain. The blocking domain's set_dev_pasid op simply is
whatever set_dev_blocking_pasid would have done on the unmanaged
domain.
identity doesn't come into this, identity domains should have a NULL
set_dev_pasid op if the driver can't support using it on a PASID.
IMHO blocking_domain->ops->set_dev_pasid() is just a more logical name
than domain->ops->set_dev_blocking_pasid() - especially since VFIO
would like drivers to implement blocking domain anyhow.
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: Robin Murphy <robin.murphy@arm.com>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>,
Christoph Hellwig <hch@infradead.org>,
Kevin Tian <kevin.tian@intel.com>,
Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
Jacob jun Pan <jacob.jun.pan@intel.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] iommu: Add blocking_domain_ops field in iommu_ops
Date: Tue, 17 May 2022 10:13:24 -0300 [thread overview]
Message-ID: <20220517131324.GU1343366@nvidia.com> (raw)
In-Reply-To: <f971aea9-8ae1-95f8-b10a-cd77e9704dc0@arm.com>
On Tue, May 17, 2022 at 01:43:03PM +0100, Robin Murphy wrote:
> FWIW from my point of view I'm happy with having a .detach_dev_pasid op
> meaning implicitly-blocked access for now.
If this is the path then lets not call it attach/detach
please. 'set_dev_pasid' and 'set_dev_blocking_pasid' are clearer
names.
> On SMMUv3, PASIDs don't mix with our current notion of
> IOMMU_DOMAIN_IDENTITY (nor the potential one for
> IOMMU_DOMAIN_BLOCKED), so giving PASIDs functional symmetry with
> devices would need significantly more work anyway.
There is no extra work in the driver, beyond SMMU having to implement
a blocking domain. The blocking domain's set_dev_pasid op simply is
whatever set_dev_blocking_pasid would have done on the unmanaged
domain.
identity doesn't come into this, identity domains should have a NULL
set_dev_pasid op if the driver can't support using it on a PASID.
IMHO blocking_domain->ops->set_dev_pasid() is just a more logical name
than domain->ops->set_dev_blocking_pasid() - especially since VFIO
would like drivers to implement blocking domain anyhow.
Jason
next prev parent reply other threads:[~2022-05-17 13:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 1:57 [PATCH 0/5] iommu: Make blocking domain static for group Lu Baolu
2022-05-16 1:57 ` Lu Baolu
2022-05-16 1:57 ` [PATCH 1/5] iommu: Rename attach_dev to set_dev in domain ops Lu Baolu
2022-05-16 1:57 ` Lu Baolu
2022-05-16 1:57 ` [PATCH 2/5] iommu: Add blocking_domain_ops field in iommu_ops Lu Baolu
2022-05-16 1:57 ` Lu Baolu
2022-05-16 7:27 ` Christoph Hellwig
2022-05-16 7:27 ` Christoph Hellwig
2022-05-16 13:05 ` Jason Gunthorpe via iommu
2022-05-16 13:05 ` Jason Gunthorpe
2022-05-16 11:22 ` Robin Murphy
2022-05-16 11:22 ` Robin Murphy
2022-05-16 13:43 ` Baolu Lu
2022-05-16 13:43 ` Baolu Lu
2022-05-16 13:57 ` Jason Gunthorpe via iommu
2022-05-16 13:57 ` Jason Gunthorpe
2022-05-17 2:37 ` Baolu Lu
2022-05-17 2:37 ` Baolu Lu
2022-05-17 12:43 ` Robin Murphy
2022-05-17 12:43 ` Robin Murphy
2022-05-17 13:13 ` Jason Gunthorpe via iommu [this message]
2022-05-17 13:13 ` Jason Gunthorpe
2022-05-18 6:43 ` Baolu Lu
2022-05-18 6:43 ` Baolu Lu
2022-05-17 13:08 ` Jason Gunthorpe via iommu
2022-05-17 13:08 ` Jason Gunthorpe
2022-05-20 8:45 ` Joerg Roedel
2022-05-20 8:45 ` Joerg Roedel
2022-05-20 11:03 ` Baolu Lu
2022-05-20 11:03 ` Baolu Lu
2022-05-16 1:57 ` [PATCH 3/5] iommu: Make blocking domain static for iommu group Lu Baolu
2022-05-16 1:57 ` Lu Baolu
2022-05-16 1:57 ` [PATCH 4/5] iommu: Use blocking domain for empty domain attaching Lu Baolu
2022-05-16 1:57 ` Lu Baolu
2022-05-16 1:57 ` [PATCH 5/5] iommu: Remove .detach_dev from iommu domain ops Lu Baolu
2022-05-16 1:57 ` 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=20220517131324.GU1343366@nvidia.com \
--to=iommu@lists.linux-foundation.org \
--cc=ashok.raj@intel.com \
--cc=hch@infradead.org \
--cc=jacob.jun.pan@intel.com \
--cc=jean-philippe@linaro.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--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.