From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: joro@8bytes.org, kevin.tian@intel.com,
suravee.suthikulpanit@amd.com, will@kernel.org,
robin.murphy@arm.com, sven@kernel.org, j@jannau.net,
jean-philippe@linaro.org, robin.clark@oss.qualcomm.com,
dwmw2@infradead.org, baolu.lu@linux.intel.com,
yong.wu@mediatek.com, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com, tjeznach@rivosinc.com,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
heiko@sntech.de, schnelle@linux.ibm.com, mjrosato@linux.ibm.com,
wens@csie.org, jernej.skrabec@gmail.com, samuel@sholland.org,
thierry.reding@gmail.com, jonathanh@nvidia.com,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-riscv@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org,
virtualization@lists.linux.dev, patches@lists.linux.dev
Subject: Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement arm_smmu_domain_test_dev
Date: Mon, 27 Oct 2025 20:26:40 -0300 [thread overview]
Message-ID: <20251027232640.GE1018328@nvidia.com> (raw)
In-Reply-To: <aPaWsEg1Y3XqsA3E@Asurada-Nvidia>
On Mon, Oct 20, 2025 at 01:08:16PM -0700, Nicolin Chen wrote:
> > I don't see any reasonable way to mitigate this??
>
> Right. It can't simply go through a regular attach_dev call since
> driver wouldn't expect any inconsistency in the core.
>
> Driver would have to be aware of the reset state, and make a copy
> of the old domain's CD/STE to use for a test_dev() during a reset.
It seems convoluted :\
IDK if you want to do that some kind of "attach but really don't" flag
so all the tracking was kept, just the STE was forced to blocking.
Then since all the fake attaches are tracked and validated switching
to a real ste shouldn't fail.
For instance SMMU could continue to build the CD table and act like
the CD is active, but the STE wouldn't point to it.
Basically, this approach doesn't seem to solve all the problems, it
reduces them sure, but there are still enough gaps.
So I think we either have to live with them and call it a user bug to
change the domain improperly during FLR.. If it happens dump the
translation into blocking and move on..
Or we have to do some kind of fake attach tracking which doesn't sound
appealing..
Jason
next prev parent reply other threads:[~2025-10-27 23:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 0:04 [PATCH v1 00/20] iommu: Introduce and roll out test_dev domain op Nicolin Chen
2025-10-13 0:04 ` [PATCH v1 01/20] iommu: Lock group->mutex in iommu_deferred_attach() Nicolin Chen
2025-10-13 0:04 ` [PATCH v1 02/20] iommu: Introduce a test_dev domain op and an internal helper Nicolin Chen
2025-10-13 9:53 ` Niklas Schnelle
2025-10-13 17:22 ` Nicolin Chen
2025-10-14 14:20 ` Niklas Schnelle
2025-10-20 16:27 ` Jason Gunthorpe
2025-10-20 18:51 ` Nicolin Chen
2025-10-27 23:23 ` Jason Gunthorpe
2025-10-28 4:37 ` Nicolin Chen
2025-10-27 23:18 ` Nicolin Chen
2025-10-30 8:47 ` Tian, Kevin
2025-10-30 19:43 ` Nicolin Chen
2025-11-03 18:54 ` Jason Gunthorpe
2025-11-05 6:57 ` Tian, Kevin
2025-11-05 18:18 ` Nicolin Chen
2025-11-07 18:54 ` Jason Gunthorpe
2025-11-07 18:58 ` Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 03/20] iommu/arm-smmu-v3: Implement arm_smmu_domain_test_dev Nicolin Chen
2025-10-20 16:32 ` Jason Gunthorpe
2025-10-20 20:08 ` Nicolin Chen
2025-10-27 23:26 ` Jason Gunthorpe [this message]
2025-10-28 6:54 ` Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 04/20] iommu/intel: Implement test_dev callbacks to domain ops Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 05/20] iommu/amd: " Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 06/20] iommu/arm-smmu: Implement arm_smmu_test_dev Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 07/20] iommu/qcom_iommu: Implement test_dev callbacks to domain ops Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 08/20] iommu/riscv: Implement riscv_iommu_test_paging_domain Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 09/20] iommu/mkt_iommu: Implement mtk_iommu_test_device Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 10/20] iommu/apple-dart: Implement test_dev callbacks to domain ops Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 11/20] iommu/ipmmu-vmsa: Implement ipmmu_domain_test_device Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 12/20] iommu/sun50i-iommu: Implement sun50i_iommu_domain_test_device Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 13/20] iommu/rockchip-iommu: Implement rk_iommu_identity_test_dev Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 14/20] iommu/msm_iommu: Implement msm_iommu_domain_test_dev Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 15/20] iommu/fsl_pamu_domain: Implement fsl_pamu_domain_test_device Nicolin Chen
2025-10-15 22:02 ` Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 16/20] iommu/omap-iommu: Implement omap_iommu_domain_test_dev Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 17/20] iommu/s390-iommu: Implement s390_iommu_domain_test_device Nicolin Chen
2025-10-13 9:59 ` Niklas Schnelle
2025-10-13 0:05 ` [PATCH v1 18/20] iommufd/selftest: Implement mock_domain_nop_test Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 19/20] iommu/virtio-iommu: Implement viommu_domain_test_dev Nicolin Chen
2025-10-13 0:05 ` [PATCH v1 20/20] iommu/tegra-smmu: Implement tegra_smmu_domain_test_dev Nicolin Chen
2025-10-20 16:24 ` [PATCH v1 00/20] iommu: Introduce and roll out test_dev domain op Jason Gunthorpe
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=20251027232640.GE1018328@nvidia.com \
--to=jgg@nvidia.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=aou@eecs.berkeley.edu \
--cc=asahi@lists.linux.dev \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux.dev \
--cc=j@jannau.net \
--cc=jean-philippe@linaro.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=palmer@dabbelt.com \
--cc=patches@lists.linux.dev \
--cc=pjw@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=samuel@sholland.org \
--cc=schnelle@linux.ibm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=sven@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=tjeznach@rivosinc.com \
--cc=virtualization@lists.linux.dev \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.com \
/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;
as well as URLs for NNTP newsgroup(s).