From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, jgg@nvidia.com, robin.murphy@arm.com,
joro@8bytes.org, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
skolothumtho@nvidia.com, xueshuai@linux.alibaba.com,
smostafa@google.com
Subject: Re: [PATCH rc v6 3/4] iommu/arm-smmu-v3: Mark STE EATS safe when computing the update sequence
Date: Wed, 14 Jan 2026 15:58:03 +0000 [thread overview]
Message-ID: <aWe9C8wwfszvqxR6@google.com> (raw)
In-Reply-To: <b8055e0f0f1b4473db2583586350b4f7aa8f3b4c.1768248467.git.nicolinc@nvidia.com>
On Mon, Jan 12, 2026 at 12:20:16PM -0800, Nicolin Chen wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
>
> If a VM wants to toggle EATS off at the same time as changing the CFG, the
> hypervisor will see EATS change to 0 and insert a V=0 breaking update into
> the STE even though the VM did not ask for that.
>
> In bare metal, EATS is ignored by CFG=ABORT/BYPASS, which is why this does
> not cause a problem until we have nested where CFG is always a variation of
> S2 trans that does use EATS.
>
> Relax the rules for EATS sequencing, we don't need it to be exact because
> the enclosing code will always disable ATS at the PCI device if we are
> changing EATS. This ensures there are no ATS transactions that can race
> with an EATS change so we don't need to carefully sequence these bits.
>
> Fixes: 1e8be08d1c91 ("iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index ccd6357fa5a8..58008fe94ab3 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -1096,6 +1096,24 @@ void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target,
> * fault records even when MEV == 0.
> */
> safe_bits[1] |= cpu_to_le64(STRTAB_STE_1_MEV);
> +
> + /*
> + * When a STE comes to change EATS the sequencing code in the attach
> + * logic already will have the PCI cap for ATS disabled. Thus at this
> + * moment we can expect that the device will not generate ATS queries
> + * and so we don't care about the sequencing of EATS. The purpose of
> + * EATS is to protect the system from hostile untrusted devices that
> + * issue ATS when the PCI config space is disabled. However, if EATS
> + * is being changed then we already must be trusting the device since
> + * the EATS security block is being disabled.
> + *
> + * Note: Since we moved the EATS update to the first phase, changing
> + * S2S and EATS might transiently set S2S=1 and EATS=1, resulting in
> + * a bad STE. See "5.2 Stream Table Entry". In such a case, we can't
> + * do a hitless update.
> + */
> + if (!((cur[2] | target[2]) & cpu_to_le64(STRTAB_STE_2_S2S)))
> + safe_bits[1] |= cpu_to_le64(STRTAB_STE_1_EATS);
I understand what we're trying to do here but isn't this implicitly
saying it is safe to transition hitlessly to any non-zero EATS value,
including S1CHK or RSVD. S1CHK might have other config dependencies?
> }
> EXPORT_SYMBOL_IF_KUNIT(arm_smmu_get_ste_update_safe);
>
Thanks,
Praan
next prev parent reply other threads:[~2026-01-14 15:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 20:20 [PATCH rc v6 0/4] iommu/arm-smmu-v3: Fix hitless STE update in nesting cases Nicolin Chen
2026-01-12 20:20 ` [PATCH rc v6 1/4] iommu/arm-smmu-v3: Add update_safe bits to fix STE update sequence Nicolin Chen
2026-01-14 15:49 ` Pranjal Shrivastava
2026-01-12 20:20 ` [PATCH rc v6 2/4] iommu/arm-smmu-v3: Mark STE MEV safe when computing the " Nicolin Chen
2026-01-14 15:50 ` Pranjal Shrivastava
2026-01-12 20:20 ` [PATCH rc v6 3/4] iommu/arm-smmu-v3: Mark STE EATS " Nicolin Chen
2026-01-14 15:58 ` Pranjal Shrivastava [this message]
2026-01-14 16:15 ` Jason Gunthorpe
2026-01-14 16:59 ` Pranjal Shrivastava
2026-01-12 20:20 ` [PATCH rc v6 4/4] iommu/arm-smmu-v3-test: Add nested s1bypass/s1dssbypass coverage Nicolin Chen
2026-01-14 15:58 ` Pranjal Shrivastava
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=aWe9C8wwfszvqxR6@google.com \
--to=praan@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=skolothumtho@nvidia.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.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 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.