[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251219155151.GA373575@nvidia.com>
Date: Fri, 19 Dec 2025 11:51:51 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: will@...nel.org, jean-philippe@...aro.org, robin.murphy@....com,
joro@...tes.org, balbirs@...dia.com, miko.lenczewski@....com,
peterz@...radead.org, kevin.tian@...el.com, praan@...gle.com,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs
when attaching masters
On Wed, Dec 17, 2025 at 03:24:30PM -0800, Nicolin Chen wrote:
> + *cur = inv;
> + switch (type) {
> + case INV_TYPE_S1_ASID:
> + if (master->smmu->features & ARM_SMMU_FEAT_E2H) {
> + cur->size_opcode = CMDQ_OP_TLBI_EL2_VA;
> + cur->nsize_opcode = CMDQ_OP_TLBI_EL2_ASID;
> + } else {
> + cur->size_opcode = CMDQ_OP_TLBI_NH_VA;
> + cur->nsize_opcode = CMDQ_OP_TLBI_NH_ASID;
There is a tricky little gotcha here that probably requires a comment.
NH_VA and NH_ASID both take (VMID,ASID) as input since the ASID is
always scoped to a single VMID.
In this case the invalidation logic always wires the VMID to zero,
which is also the VMID the driver uses for S1 tables when the S2 is in
bypass.
Which is fine, we don't support an actual S1 table on top of a S2
table where we issue invalidations through the invs array.
So maybe:
For S1 page tables the driver always uses VMID=0, and the
invalidation logic for this type will set it as well.
Jason
Powered by blists - more mailing lists