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: Mon, 16 May 2022 10:57:41 -0300 [thread overview]
Message-ID: <20220516135741.GV1343366@nvidia.com> (raw)
In-Reply-To: <8a0fc6cf-f46e-f17e-2b76-099ada1683c3@arm.com>
On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
> On 2022-05-16 02:57, Lu Baolu wrote:
> > Each IOMMU driver must provide a blocking domain ops. If the hardware
> > supports detaching domain from device, setting blocking domain equals
> > detaching the existing domain from the deivce. Otherwise, an UNMANAGED
> > domain without any mapping will be used instead.
>
> Unfortunately that's backwards - most of the implementations of .detach_dev
> are disabling translation entirely, meaning the device ends up effectively
> in passthrough rather than blocked.
Ideally we'd convert the detach_dev of every driver into either
a blocking or identity domain. The trick is knowing which is which..
Guessing going down the list:
apple dart - blocking, detach_dev calls apple_dart_hw_disable_dma() same as
IOMMU_DOMAIN_BLOCKED
[I wonder if this drive ris wrong in other ways though because
I dont see a remove_streams in attach_dev]
exynos - this seems to disable the 'sysmmu' so I'm guessing this is
identity
iommu-vmsa - Comment says 'disable mmu translaction' so I'm guessing
this is idenity
mkt_v1 - Code looks similar to mkt, which is probably identity.
rkt - No idea
sprd - No idea
sun50i - This driver confusingly treats identity the same as
unmanaged, seems wrong, no idea.
amd - Not sure, clear_dte_entry() seems to set translation on but points
the PTE to 0 ? Based on the spec table 8 I would have expected
TV to be clear which would be blocking. Maybe a bug??
arm smmu qcomm - not sure
intel - blocking
These doesn't support default domains, so detach_dev should return
back to DMA API ownership, which is either identity or something weird:
fsl_pamu - identity due to the PPC use of dma direct
msm
mkt
omap
s390 - platform DMA ops
terga-gart - Usually something called a GART would be 0 length once
disabled, guessing blocking?
tegra-smmu
So, the approach here should be to go driver by driver and convert
detach_dev to either identity, blocking or just delete it entirely,
excluding the above 7 that don't support default domains. And get acks
from the driver owners.
> Conversely, at least arm-smmu and arm-smmu-v3 could implement
> IOMMU_DOMAIN_BLOCKED properly with fault-type S2CRs and STEs
> respectively, it just needs a bit of wiring up.
Given that vfio now uses them it seems worthwhile to do..
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: Lu Baolu <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: Mon, 16 May 2022 10:57:41 -0300 [thread overview]
Message-ID: <20220516135741.GV1343366@nvidia.com> (raw)
In-Reply-To: <8a0fc6cf-f46e-f17e-2b76-099ada1683c3@arm.com>
On Mon, May 16, 2022 at 12:22:08PM +0100, Robin Murphy wrote:
> On 2022-05-16 02:57, Lu Baolu wrote:
> > Each IOMMU driver must provide a blocking domain ops. If the hardware
> > supports detaching domain from device, setting blocking domain equals
> > detaching the existing domain from the deivce. Otherwise, an UNMANAGED
> > domain without any mapping will be used instead.
>
> Unfortunately that's backwards - most of the implementations of .detach_dev
> are disabling translation entirely, meaning the device ends up effectively
> in passthrough rather than blocked.
Ideally we'd convert the detach_dev of every driver into either
a blocking or identity domain. The trick is knowing which is which..
Guessing going down the list:
apple dart - blocking, detach_dev calls apple_dart_hw_disable_dma() same as
IOMMU_DOMAIN_BLOCKED
[I wonder if this drive ris wrong in other ways though because
I dont see a remove_streams in attach_dev]
exynos - this seems to disable the 'sysmmu' so I'm guessing this is
identity
iommu-vmsa - Comment says 'disable mmu translaction' so I'm guessing
this is idenity
mkt_v1 - Code looks similar to mkt, which is probably identity.
rkt - No idea
sprd - No idea
sun50i - This driver confusingly treats identity the same as
unmanaged, seems wrong, no idea.
amd - Not sure, clear_dte_entry() seems to set translation on but points
the PTE to 0 ? Based on the spec table 8 I would have expected
TV to be clear which would be blocking. Maybe a bug??
arm smmu qcomm - not sure
intel - blocking
These doesn't support default domains, so detach_dev should return
back to DMA API ownership, which is either identity or something weird:
fsl_pamu - identity due to the PPC use of dma direct
msm
mkt
omap
s390 - platform DMA ops
terga-gart - Usually something called a GART would be 0 length once
disabled, guessing blocking?
tegra-smmu
So, the approach here should be to go driver by driver and convert
detach_dev to either identity, blocking or just delete it entirely,
excluding the above 7 that don't support default domains. And get acks
from the driver owners.
> Conversely, at least arm-smmu and arm-smmu-v3 could implement
> IOMMU_DOMAIN_BLOCKED properly with fault-type S2CRs and STEs
> respectively, it just needs a bit of wiring up.
Given that vfio now uses them it seems worthwhile to do..
Jason
next prev parent reply other threads:[~2022-05-16 13:57 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 [this message]
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
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=20220516135741.GV1343366@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.