From: Baolu Lu <baolu.lu@linux.intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Kevin Tian <kevin.tian@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Dmytro Maluka <dmaluka@chromium.org>,
Samiullah Khawaja <skhawaja@google.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] iommu: Lift and generalize the STE/CD update code from SMMUv3
Date: Mon, 16 Mar 2026 14:24:57 +0800 [thread overview]
Message-ID: <02344098-c2da-4634-8f34-e03c88d030a2@linux.intel.com> (raw)
In-Reply-To: <abOjJf4HJ50vCIyg@Asurada-Nvidia>
On 3/13/26 13:39, Nicolin Chen wrote:
> Hi Baolu,
Hi Nicolin,
Thanks for the comments.
>
> On Mon, Mar 09, 2026 at 02:06:41PM +0800, Lu Baolu wrote:
>> +struct entry_sync_writer_ops64;
>> +struct entry_sync_writer64 {
>> + const struct entry_sync_writer_ops64 *ops;
>> + size_t num_quantas;
>> + size_t vbit_quanta;
>> +};
>
> Though I could guess what the @num_quantas and @vbit_quanta likely
> mean, it'd be nicer to have some notes elaborating them.
Yes. I will make it like this,
struct entry_sync_writer64 {
const struct entry_sync_writer_ops64 *ops;
/* Total size of the entry in atomic units: */
size_t num_quantas;
/* The index of the quanta containing the Valid bit: */
size_t vbit_quanta;
};
The same to entry_sync_writer128.
>
>> +/*
>> + * Figure out if we can do a hitless update of entry to become target. Returns a
>> + * bit mask where 1 indicates that a quanta word needs to be set disruptively.
>> + * unused_update is an intermediate value of entry that has unused bits set to
>> + * their new values.
>> + */
>> +static u8 NS(entry_quanta_diff)(struct entry_sync_writer *writer,
>> + const quanta_t *entry, const quanta_t *target,
>> + quanta_t *unused_update, quanta_t *memory)
>> +{
>> + quanta_t *target_used = memory + writer->num_quantas * 1;
>> + quanta_t *cur_used = memory + writer->num_quantas * 2;
>
> Should we have a kdoc somewhere mentioning that the two arrays are
> neighbors (IIUIC)?
The library uses a single block of scratchpad memory and offsets into
it. A WARN_ON() is added in NS(entry_sync_write) to ensure this:
if (WARN_ON(memory_len !=
ENTRY_SYNC_MEMORY_LEN(writer) * sizeof(*memory)))
return;
How about adding below comments around this WARN_ON()?
/*
* The scratchpad memory is organized into three neighbors:
* 1. [0, num_quantas): 'unused_update' - intermediate state with
* ignored bits updated.
* 2. [num_quantas, 2*num_quantas): 'target_used' - bits active in
* the target state.
* 3. [2*num_quantas, 3*num_quantas): 'cur_used' - bits active in
* the current state.
*/
>> + u8 used_qword_diff = 0;
>
> It seems to me that we want use "quanta" v.s. "qword"? 128 bits can
> be called "dqword" as well though.
Yes. "qword" is a bit too x86-centric. Since the library is designed
around the concept of an atomic "quanta" of update, I will unify the
terminology ("quanta" in general) and use used_quanta_diff
>
>> + unsigned int i;
>> +
>> + writer->ops->get_used(entry, cur_used);
>> + writer->ops->get_used(target, target_used);
>
> SMMU has get_update_safe now. Can we take it together?
I will look into the SMMUv3 get_update_safe implementation. Or integrate
that specially when we transition the ARM SMMUv3 driver to use this
generic entry_sync library.
>
>> +void NS(entry_sync_write)(struct entry_sync_writer *writer, quanta_t *entry,
>> + const quanta_t *target, quanta_t *memory,
>> + size_t memory_len)
>> +{
>> + quanta_t *unused_update = memory + writer->num_quantas * 0;
>> + u8 used_qword_diff;
>> +
>> + if (WARN_ON(memory_len !=
>> + ENTRY_SYNC_MEMORY_LEN(writer) * sizeof(*memory)))
>> + return;
>> +
>> + used_qword_diff = NS(entry_quanta_diff)(writer, entry, target,
>> + unused_update, memory);
>> + if (hweight8(used_qword_diff) == 1) {
>> + /*
>> + * Only one quanta needs its used bits to be changed. This is a
>> + * hitless update, update all bits the current entry is ignoring
>> + * to their new values, then update a single "critical quanta"
>> + * to change the entry and finally 0 out any bits that are now
>> + * unused in the target configuration.
>> + */
>> + unsigned int critical_qword_index = ffs(used_qword_diff) - 1;
>> +
>> + /*
>> + * Skip writing unused bits in the critical quanta since we'll
>> + * be writing it in the next step anyways. This can save a sync
>> + * when the only change is in that quanta.
>> + */
>> + unused_update[critical_qword_index] =
>> + entry[critical_qword_index];
>> + NS(entry_set)(writer, entry, unused_update, 0,
>> + writer->num_quantas);
>> + NS(entry_set)(writer, entry, target, critical_qword_index, 1);
>> + NS(entry_set)(writer, entry, target, 0, writer->num_quantas);
>> + } else if (used_qword_diff) {
>> + /*
>> + * At least two quantas need their inuse bits to be changed.
>> + * This requires a breaking update, zero the V bit, write all
>> + * qwords but 0, then set qword 0
>> + */
>
> Still, it'd be nicer to unify the wording between "quanta" and
> "qword".
Yes.
>
> [..]
>> +EXPORT_SYMBOL(NS(entry_sync_write));
>
> There is also a KUNIT test coverage in arm-smmu-v3 for all of these
> functions. Maybe we can make that generic as well?
Same here.
>
>> +#define entry_sync_writer entry_sync_writer64
>> +#define quanta_t __le64
> [..]
>> +#define entry_sync_writer entry_sync_writer128
>> +#define quanta_t u128
>
> u64 can be called 64 too, though we might not have use case for now.
>
> But maybe we could just call them:
> entry_sync_writer_le64
> entry_sync_writer_u128
> ?
I'm fine with the new naming. It is more explicit. I will update the
names unless there are further objections.
Thanks,
baolu
next prev parent reply other threads:[~2026-03-16 6:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 6:06 [PATCH 0/8] iommu/vt-d: Hitless PASID updates via entry_sync Lu Baolu
2026-03-09 6:06 ` [PATCH 1/8] iommu: Lift and generalize the STE/CD update code from SMMUv3 Lu Baolu
2026-03-09 23:33 ` Samiullah Khawaja
2026-03-10 0:06 ` Samiullah Khawaja
2026-03-14 8:13 ` Baolu Lu
2026-03-16 9:51 ` Will Deacon
2026-03-18 3:10 ` Baolu Lu
2026-03-23 12:55 ` Jason Gunthorpe
2026-03-24 5:30 ` Baolu Lu
2026-03-16 16:35 ` Samiullah Khawaja
2026-03-18 3:23 ` Baolu Lu
2026-03-13 5:39 ` Nicolin Chen
2026-03-16 6:24 ` Baolu Lu [this message]
2026-03-23 12:59 ` Jason Gunthorpe
2026-03-24 5:49 ` Baolu Lu
2026-03-09 6:06 ` [PATCH 2/8] iommu/vt-d: Add entry_sync support for PASID entry updates Lu Baolu
2026-03-09 13:41 ` Jason Gunthorpe
2026-03-11 8:42 ` Baolu Lu
2026-03-11 12:23 ` Jason Gunthorpe
2026-03-12 7:51 ` Baolu Lu
2026-03-12 7:50 ` Baolu Lu
2026-03-12 11:44 ` Jason Gunthorpe
2026-03-15 8:11 ` Baolu Lu
2026-03-23 13:07 ` Jason Gunthorpe
2026-03-24 6:22 ` Baolu Lu
2026-03-24 12:53 ` Jason Gunthorpe
2026-03-09 6:06 ` [PATCH 3/8] iommu/vt-d: Require CMPXCHG16B for PASID support Lu Baolu
2026-03-09 13:42 ` Jason Gunthorpe
2026-03-12 7:59 ` Baolu Lu
2026-03-09 6:06 ` [PATCH 4/8] iommu/vt-d: Add trace events for PASID entry sync updates Lu Baolu
2026-03-09 6:06 ` [PATCH 5/8] iommu/vt-d: Use intel_pasid_write() for first-stage setup Lu Baolu
2026-03-09 6:06 ` [PATCH 6/8] iommu/vt-d: Use intel_pasid_write() for second-stage setup Lu Baolu
2026-03-09 6:06 ` [PATCH 7/8] iommu/vt-d: Use intel_pasid_write() for pass-through setup Lu Baolu
2026-03-09 6:06 ` [PATCH 8/8] iommu/vt-d: Use intel_pasid_write() for nested setup 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=02344098-c2da-4634-8f34-e03c88d030a2@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=dmaluka@chromium.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=skhawaja@google.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