From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
Kevin Tian <kevin.tian@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
joro@8bytes.org, David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/6] iommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE field
Date: Wed, 15 Jul 2026 19:41:50 +0000 [thread overview]
Message-ID: <alfifgOM_YwTAP0y@google.com> (raw)
In-Reply-To: <3f0c3e7b7e9177586d7e545d8089ead4ef7890f0.1784054606.git.nicolinc@nvidia.com>
On Tue, Jul 14, 2026 at 11:48:47AM -0700, Nicolin Chen wrote:
> An SMMU implementing SMMU_IDR5.DS extends the range invalidation commands:
> the SCALE field grows a 6th bit, raising its maximum value from 31 to 39,
> and TTL == 0b01 becomes a valid level hint for a 16KB translation granule.
>
> Add a new ARM_SMMU_FEAT_DS feature detecting the DS bit, and widen the
> CMDQ_TLBI_0_SCALE field to its architectural 6 bits. Mask the scale value
> explicitly in arm_smmu_cmdq_batch_add_range(), so the range invalidation
> path emits the same commands as before, keeping the pre-existing 5-bit
> truncation of a scale above 31.
>
> Also list DS as a valid IDR5 field in the iommu_hw_info_arm_smmuv3 kdoc:
> iommufd has always reported the raw IDR5 register, so a VMM may conclude
> from that bit alone that it can expose DS to its guest.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object")
> Cc: stable@vger.kernel.org # needed by the subsequent fix
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 4 +++-
> include/uapi/linux/iommufd.h | 4 ++--
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +++++-
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index c909c9a88538b..3c59e62978a13 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -64,6 +64,7 @@ struct arm_vsmmu;
>
> #define ARM_SMMU_IDR5 0x14
> #define IDR5_STALL_MAX GENMASK(31, 16)
> +#define IDR5_DS (1 << 7)
> #define IDR5_GRAN64K (1 << 6)
> #define IDR5_GRAN16K (1 << 5)
> #define IDR5_GRAN4K (1 << 4)
> @@ -415,7 +416,7 @@ struct arm_smmu_cmd {
>
> #define CMDQ_TLBI_0_NUM GENMASK_ULL(16, 12)
> #define CMDQ_TLBI_RANGE_NUM_MAX 31
> -#define CMDQ_TLBI_0_SCALE GENMASK_ULL(24, 20)
> +#define CMDQ_TLBI_0_SCALE GENMASK_ULL(25, 20)
> #define CMDQ_TLBI_0_VMID GENMASK_ULL(47, 32)
> #define CMDQ_TLBI_0_ASID GENMASK_ULL(63, 48)
> #define CMDQ_TLBI_1_LEAF (1UL << 0)
> @@ -921,6 +922,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_HD (1 << 22)
> #define ARM_SMMU_FEAT_S2FWB (1 << 23)
> #define ARM_SMMU_FEAT_BBML2 (1 << 24)
> +#define ARM_SMMU_FEAT_DS (1 << 25)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 0425d452d41ed..72bb0e47dc272 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -594,7 +594,7 @@ struct iommu_hw_info_vtd {
> * idr[0]: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN , CD2L, ASID16, TTF
> * idr[1]: SIDSIZE, SSIDSIZE
> * idr[3]: BBML, RIL
> - * idr[5]: VAX, GRAN64K, GRAN16K, GRAN4K
> + * idr[5]: VAX, GRAN64K, GRAN16K, GRAN4K, DS
> *
> * - S1P should be assumed to be true if a NESTED HWPT can be created
> * - VFIO/iommufd only support platforms with COHACC, it should be assumed to be
> @@ -602,7 +602,7 @@ struct iommu_hw_info_vtd {
> * - ATS is a per-device property. If the VMM describes any devices as ATS
> * capable in ACPI/DT it should set the corresponding idr.
> *
> - * This list may expand in future (eg E0PD, AIE, PBHA, D128, DS etc). It is
> + * This list may expand in future (eg E0PD, AIE, PBHA, D128 etc). It is
> * important that VMMs do not read bits outside the list to allow for
> * compatibility with future kernels. Several features in the SMMUv3
> * architecture are not currently supported by the kernel for nesting: HTTU,
> 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 a10affb483a4f..9f121f9f404ea 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2446,9 +2446,10 @@ static void arm_smmu_cmdq_batch_add_range(struct arm_smmu_device *smmu,
> /* Determine how many chunks of 2^scale size we have */
> num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
>
> + /* Keep the pre-DS 5-bit truncation when scale > 31 */
> cmd->data[0] = orig_data0 |
> FIELD_PREP(CMDQ_TLBI_0_NUM, num - 1) |
> - FIELD_PREP(CMDQ_TLBI_0_SCALE, scale);
> + FIELD_PREP(CMDQ_TLBI_0_SCALE, scale & 0x1f);
Nit: Not sure what the convention is for these things, but this cap for
host is temporary as Jason's iommupt series expands the scale when DS=1.
I'm not sure if we should note a TODO here or just leave it be for now?
This is where Jason adds DS support for Host:
https://lore.kernel.org/all/8-v2-43074a57a53a+fb95-smmu_tlbi_jgg@nvidia.com/
>
> /* range is num * 2^scale * pgsize */
> inv_range = num << (scale + tg);
> @@ -5098,6 +5099,9 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> /* Maximum number of outstanding stalls */
> smmu->evtq.max_stalls = FIELD_GET(IDR5_STALL_MAX, reg);
>
> + if (reg & IDR5_DS)
> + smmu->features |= ARM_SMMU_FEAT_DS;
> +
> /* Page sizes */
Apart from that,
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
next prev parent reply other threads:[~2026-07-15 19:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 18:48 [PATCH v4 0/6] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-07-14 18:48 ` [PATCH v4 1/6] iommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE field Nicolin Chen
2026-07-15 18:58 ` Jason Gunthorpe
2026-07-15 19:41 ` Pranjal Shrivastava [this message]
2026-07-15 20:00 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 2/6] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands Nicolin Chen
2026-07-15 19:00 ` Jason Gunthorpe
2026-07-15 19:54 ` Pranjal Shrivastava
2026-07-14 18:48 ` [PATCH v4 3/6] iommufd: Iterate the cache invalidation array in the core Nicolin Chen
2026-07-15 20:03 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 4/6] iommufd/selftest: Convert cache invalidation mocks to the core array loop Nicolin Chen
2026-07-14 18:48 ` [PATCH v4 5/6] iommu/arm-smmu-v3-iommufd: Convert cache invalidation " Nicolin Chen
2026-07-15 20:05 ` Jason Gunthorpe
2026-07-14 18:48 ` [PATCH v4 6/6] iommu/vt-d: Convert nested " Nicolin Chen
2026-07-15 20:15 ` [PATCH v4 0/6] iommufd: Iterate the cache invalidation array in the core Jason Gunthorpe
2026-07-15 20:30 ` Nicolin Chen
2026-07-16 15:18 ` Jason Gunthorpe
2026-07-16 16:20 ` 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=alfifgOM_YwTAP0y@google.com \
--to=praan@google.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--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.