From d501d66815eeb0e6641ce61e7eeb2beea19eadf5 Mon Sep 17 00:00:00 2001 From: Ashish Mhetre Date: Sun, 26 Jul 2026 08:19:03 +0000 Subject: iommu/arm-smmu-v3-iommufd: Report CFGI/TLBI-repeat erratum A guest with access to VCMDQ generates its own invalidation commands and must apply any invalidation errata before submitting them. If the host also repeats those commands, each affected invalidation is issued four times instead of twice. Add IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI to report the CFGI/TLBI-repeat erratum to user space. This allows the VMM to expose the erratum to the guest or apply the workaround itself. Use the raw __arm_smmu_cmdq_issue_cmdlist() helper for user-provided invalidations so the host does not apply the workaround a second time. Add arm_smmu_erratum_repeat_tlbi_cfgi() to query the static key when populating the SMMUv3 hardware information. Signed-off-by: Ashish Mhetre Reviewed-by: Nicolin Chen Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon --- include/uapi/linux/iommufd.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'include') diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h index 0425d452d41e..f73a392b3d3f 100644 --- a/include/uapi/linux/iommufd.h +++ b/include/uapi/linux/iommufd.h @@ -574,11 +574,22 @@ struct iommu_hw_info_vtd { __aligned_u64 ecap_reg; }; +/** + * enum iommu_hw_info_arm_smmuv3_flags - Flags for ARM SMMUv3 hw_info + * @IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI: + * If set, user space must issue TLBI/CFGI+SYNC commands twice due to + * hardware erratum T264-SMMU-3. See the description at + * arm_smmu_erratum_repeat_tlbi_cfgi_key. + */ +enum iommu_hw_info_arm_smmuv3_flags { + IOMMU_HW_INFO_ARM_SMMUV3_ERRATA_REPEAT_TLBI_CFGI = 1 << 0, +}; + /** * struct iommu_hw_info_arm_smmuv3 - ARM SMMUv3 hardware information * (IOMMU_HW_INFO_TYPE_ARM_SMMUV3) * - * @flags: Must be set to 0 + * @flags: Combination of enum iommu_hw_info_arm_smmuv3_flags * @__reserved: Must be 0 * @idr: Implemented features for ARM SMMU Non-secure programming interface * @iidr: Information about the implementation and implementer of ARM SMMU, -- cgit From 773f2b9e367019c03ed18f2736c8f67307305088 Mon Sep 17 00:00:00 2001 From: Nicolin Chen Date: Tue, 28 Jul 2026 10:33:33 -0700 Subject: iommu/arm-smmu-v3: Support IDR5.DS and widen the TLBI SCALE field 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 Reviewed-by: Jason Gunthorpe Reviewed-by: Pranjal Shrivastava Assisted-by: Claude:claude-fable-5 Signed-off-by: Nicolin Chen Signed-off-by: Will Deacon --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +++++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 4 +++- include/uapi/linux/iommufd.h | 4 ++-- 3 files changed, 10 insertions(+), 4 deletions(-) (limited to 'include') 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 de5fba0b6d09..2587c33c778f 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2511,9 +2511,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); /* range is num * 2^scale * pgsize */ inv_range = num << (scale + tg); @@ -5197,6 +5198,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 */ if (reg & IDR5_GRAN64K) smmu->pgsize_bitmap |= SZ_64K | SZ_512M; 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 98191075242a..50f8321e979c 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -65,6 +65,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) @@ -417,7 +418,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) @@ -925,6 +926,7 @@ struct arm_smmu_device { #define ARM_SMMU_FEAT_S2FWB (1 << 23) #define ARM_SMMU_FEAT_BBML2 (1 << 24) #define ARM_SMMU_FEAT_HAFT (1 << 25) +#define ARM_SMMU_FEAT_DS (1 << 26) 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 f73a392b3d3f..c6851c7655c6 100644 --- a/include/uapi/linux/iommufd.h +++ b/include/uapi/linux/iommufd.h @@ -605,7 +605,7 @@ enum iommu_hw_info_arm_smmuv3_flags { * 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 @@ -613,7 +613,7 @@ enum iommu_hw_info_arm_smmuv3_flags { * - 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, -- cgit From 1c677d8a2c3cbc22287ac34483e6b2b7b20ddf52 Mon Sep 17 00:00:00 2001 From: Kevin Tian Date: Wed, 5 Aug 2026 07:43:07 +0800 Subject: iommu/vt-d: Support the new DMA_REMAP_OPT_OUT flag bit Some BIOS already provides config options to expose/hide VT-d units as a whole to/from system software. A new demand is to allow exposing VT-d units but requesting system software to disable DMA remapping while sustaining interrupt remapping. This can be communicated now by setting the new DMA_REMAP_OPT_OUT flag bit in the DMAR table, as introduced in VT-d spec v5.2 (section 8.1, DMA Remapping Reporting Structure). Introduce a new off policy (DMAR_FW_OFF) for DMA_REMAP_OPT_OUT. As the strongest off policy, it cannot be overridden by user opts or any force_on types. If tboot is enabled in the meantime, kernel will panic. It is user responsibility to configure BIOS properly. One cleanup is left for future - the DMAR flag is parsed multiple times, in detect_intel_iommu(), dmar_platform_optin() (which can be called at run-time), etc. Caching it is a cleaner way. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel --- drivers/iommu/intel/dmar.c | 34 ++++++++++++++++++++++++---------- drivers/iommu/intel/iommu.h | 4 ++++ include/linux/dmar.h | 1 + 3 files changed, 29 insertions(+), 10 deletions(-) (limited to 'include') diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index bc2f6597eb27..33bfaeafa7c6 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -930,7 +930,9 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, void *arg) * * - DMAR_FORCEON_TBOOT: tboot strictly requires DMA remapping for secure * boot hence supersedes any user opts ("iommu=off" or "intel_iommu=off") - * and weaker off policies. + * and weaker off policies. But if firmware forces DMA remapping off (by + * setting DMAR_REMAP_OPT_OUT in the DMAR table), no force_on is allowed. + * Firmware settings must be changed to unblock tboot. * * - DMAR_FORCEON_PLATFORM: external-facing devices requires DMA * remapping to prevent malicious downstream external devices from @@ -939,6 +941,7 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, void *arg) * * In a nutshell, "trusted boot environment" is considered stronger than * "user choices", which in turn is stronger than "platform opt-in hint". + * But they are all meaningless when it's forced off by "firmware". */ bool dmar_can_force_on(enum dmar_force_on force_on) { @@ -976,31 +979,42 @@ static bool dmar_required(void) void __init detect_intel_iommu(void) { - int ret; struct dmar_res_callback validate_drhd_cb = { .cb[ACPI_DMAR_TYPE_HARDWARE_UNIT] = &dmar_validate_one_drhd, .ignore_unhandled = true, }; + struct acpi_table_dmar *dmar; + int ret; down_write(&dmar_global_lock); if (no_iommu) dmar_policy = DMAR_USER_OFF; ret = dmar_table_detect(); - if (!ret) - ret = dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl, - &validate_drhd_cb); - if (!ret && !iommu_detected && dmar_required()) { + if (!ret) { + dmar = (struct acpi_table_dmar *)dmar_tbl; + ret = dmar_walk_dmar_table(dmar, &validate_drhd_cb); + } + + if (ret) + goto out; + + if (dmar->flags & DMAR_REMAP_OPT_OUT) { + dmar_policy = DMAR_FW_OFF; + pr_info("Firmware forces DMA remapping off\n"); + pr_info("Any user opt or tboot/platform force_on will be ignored\n"); + } + + if (!iommu_detected && dmar_required()) { iommu_detected = 1; /* Make sure ACS will be enabled */ pci_request_acs(); } - if (!ret) { - x86_init.iommu.iommu_init = intel_iommu_init; - x86_platform.iommu_shutdown = intel_iommu_shutdown; - } + x86_init.iommu.iommu_init = intel_iommu_init; + x86_platform.iommu_shutdown = intel_iommu_shutdown; +out: if (dmar_tbl) { acpi_put_table(dmar_tbl); dmar_tbl = NULL; diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 9805edb8c7df..656cd311ed9a 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1375,6 +1375,9 @@ enum dmar_force_on { * - DMAR_USER_OFF * turn off by user opts ("intel_iommu=off" or "iommu=off"). * + * - DMAR_FW_OFF + * turn off due to firmware opt-out (DMAR_REMAP_OPT_OUT) + * * - '0' is invalid, compared to decide the on/off policy * */ @@ -1382,6 +1385,7 @@ enum dmar_force_on { #define DMAR_ON 1 #define DMAR_DEFAULT_OFF -1 #define DMAR_USER_OFF -2 +#define DMAR_FW_OFF -3 extern int dmar_policy; static inline bool dmar_policy_on(void) diff --git a/include/linux/dmar.h b/include/linux/dmar.h index 692b2b445761..63e35df2cef4 100644 --- a/include/linux/dmar.h +++ b/include/linux/dmar.h @@ -24,6 +24,7 @@ struct acpi_dmar_header; #define DMAR_INTR_REMAP 0x1 #define DMAR_X2APIC_OPT_OUT 0x2 #define DMAR_PLATFORM_OPT_IN 0x4 +#define DMAR_REMAP_OPT_OUT 0x8 struct intel_iommu; -- cgit