From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <will@kernel.org>, <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>,
<praan@google.com>
Subject: Re: [PATCH rc v1 1/4] iommu/arm-smmu-v3: Add ignored bits to fix STE update sequence
Date: Sat, 6 Dec 2025 20:37:30 -0800 [thread overview]
Message-ID: <aTUEikcWXWwKAS/1@nvidia.com> (raw)
In-Reply-To: <20251206195752.GI1219718@nvidia.com>
On Sat, Dec 06, 2025 at 03:57:52PM -0400, Jason Gunthorpe wrote:
> I think that supports more that we should do what Shuai suggested and
> keep used as-is.
Yes, that will be probably cleaner.
> Then ignored should be adjusted by the used: Only if both used are 1
> should the bit become ignored. Otherwise we can rely on which ever
> used is 0 to generate the hitless update.
Hmm, not sure why it has to be both used.
The unused_update is computed using cur_used, and the equation for
used_qword_diff is computed using target_used, either of which can
be affected by ignored bits, right?
E.g.
if cur_used[] includes ING bit, target_used doesn't:
// target must unset IGN bit, last equation isn't affected
if cur sets IGN bit
cur_used should exclude IGN bit
if cur unsets IGN bit
not affected
if cur_used[] doesn't include ignores, target_used does:
// cur must unset IGN bit, cur_used isn't affected
if target sets IGN bit:
last equation must exclude IGN bit on both sides
if target unsets IGN bit:
not affected
> @@ -1109,6 +1118,7 @@ static u8 arm_smmu_entry_qword_diff(struct arm_smmu_entry_writer *writer,
> WARN_ON_ONCE(target[i] & ~target_used[i]);
>
> /* Bits can change because they are not currently being used */
> + cur_used[i] &= ~ignored[i];
> unused_update[i] = (entry[i] & cur_used[i]) |
> (target[i] & ~cur_used[i]);
If one of ignored bits is set in entry[i] but unset in target[i],
the unused_update will first mask it away, resulting in an extra
unnecessary update (though it's still hitless).
So, I think this might be better:
- cur_used[i] &= ~ignored[i];
+ cur_unused[i] = ~cur_used[i] | ignored[i];
unused_update[i] = (entry[i] & cur_used[i]) |
- (target[i] & ~cur_used[i]);
+ (target[i] & cur_unused[i]);
Because cur_used includes ignored, the unused_update will retain
the ignored bits from entry. On the other hand, having cur_unused
will also retain the ignored bits from target.
One more change that we need is at the last equation:
- if ((unused_update[i] & target_used[i]) != target[i])
+ if ((unused_update[i] & target_used[i] & ~ignored[i]) !=
+ (target[i] & ~ignored[i]))
Either side might have the ignored bits, so we have to suppress
ignored on both sides, which is required in the similar routine
in arm_smmu_entry_differs_in_used_bits() of the kunit code.
With these additional changes, nesting sanity and kunit test are
both passing. I will do a few more tests to make sure things are
okay, before wrapping up the v2. Please let me know if all these
make sense to you.
Thanks
Nicolin
next prev parent reply other threads:[~2025-12-07 4:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-06 0:51 [PATCH rc v1 0/4] iommu/arm-smmu-v3: Fix hitless STE update in nesting cases Nicolin Chen
2025-12-06 0:52 ` [PATCH rc v1 1/4] iommu/arm-smmu-v3: Add ignored bits to fix STE update sequence Nicolin Chen
2025-12-06 14:19 ` Shuai Xue
2025-12-06 19:38 ` Jason Gunthorpe
2025-12-06 19:34 ` Jason Gunthorpe
2025-12-06 19:45 ` Nicolin Chen
2025-12-06 19:57 ` Jason Gunthorpe
2025-12-07 4:37 ` Nicolin Chen [this message]
2025-12-07 16:09 ` Jason Gunthorpe
2025-12-07 19:35 ` Nicolin Chen
2025-12-07 20:11 ` Nicolin Chen
2025-12-06 0:52 ` [PATCH rc v1 2/4] iommu/arm-smmu-v3: Ignore STE MEV when computing the " Nicolin Chen
2025-12-06 0:52 ` [PATCH rc v1 3/4] iommu/arm-smmu-v3: Ignore STE EATS " Nicolin Chen
2025-12-06 19:46 ` Jason Gunthorpe
2025-12-06 19:54 ` Nicolin Chen
2025-12-06 0:52 ` [PATCH rc v1 4/4] iommu/arm-smmu-v3-test: Add nested s1bypass coverage Nicolin Chen
2025-12-06 12:34 ` Shuai Xue
2025-12-06 19:42 ` Jason Gunthorpe
2025-12-06 19:50 ` Nicolin Chen
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=aTUEikcWXWwKAS/1@nvidia.com \
--to=nicolinc@nvidia.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=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=skolothumtho@nvidia.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 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).