[PATCH v5 04/17] iommu/arm-smmu-v3: Move the STE generation for S1 and S2 domains into functions
Jason Gunthorpe
jgg at nvidia.com
Fri Feb 16 09:12:17 PST 2024
On Tue, Feb 06, 2024 at 11:12:41AM -0400, Jason Gunthorpe wrote:
> +static void arm_smmu_make_s2_domain_ste(struct arm_smmu_ste *target,
> + struct arm_smmu_master *master,
> + struct arm_smmu_domain *smmu_domain)
> +{
> + struct arm_smmu_s2_cfg *s2_cfg = &smmu_domain->s2_cfg;
> +
> + memset(target, 0, sizeof(*target));
> + target->data[0] = cpu_to_le64(
> + STRTAB_STE_0_V |
> + FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S2_TRANS));
> +
> + target->data[1] = cpu_to_le64(
> + FIELD_PREP(STRTAB_STE_1_EATS,
> + master->ats_enabled ? STRTAB_STE_1_EATS_TRANS : 0) |
> + FIELD_PREP(STRTAB_STE_1_SHCFG,
> + STRTAB_STE_1_SHCFG_NON_SHARABLE));
Just so we are on the same page.. The above NON_SHARABLE is a mistake
here since v1.
It is hard to follow arm_smmu_write_strtab_ent() so we all missed that
the S2 ends up re-using the qword[1] that was installed by the
bypass/abort STE that has to be in place prior to installing the S2.
Only the S1 path sets SHCFG to 0 because the HW doesn't use it due to
the current driver not using S1DSS.
Jason
More information about the linux-arm-kernel
mailing list