[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAqFi52vU3h+DsWF@Asurada-Nvidia>
Date: Thu, 9 Mar 2023 17:19:07 -0800
From: Nicolin Chen <nicolinc@...dia.com>
To: Robin Murphy <robin.murphy@....com>
CC: <jgg@...dia.com>, <will@...nel.org>, <eric.auger@...hat.com>,
<kevin.tian@...el.com>, <baolu.lu@...ux.intel.com>,
<joro@...tes.org>, <shameerali.kolothum.thodi@...wei.com>,
<jean-philippe@...aro.org>, <linux-arm-kernel@...ts.infradead.org>,
<iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 13/14] iommu/arm-smmu-v3: Add CMDQ_OP_TLBI_NH_VAA and
CMDQ_OP_TLBI_NH_ALL
On Thu, Mar 09, 2023 at 01:44:34PM +0000, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2023-03-09 10:53, Nicolin Chen wrote:
> > With a nested translation setup, a stage-1 Context Descriptor table can be
> > managed by a guest OS in the user space. So, the kernel driver should not
> > assume that the guest OS will use a user space device driver that doesn't
> > support TLBI_NH_VAA and TLBI_NH_ALL commands.
> >
> > Add them in the arm_smmu_cmdq_build_cmd(), to prepare for support of these
> > two TLBI invalidation requests from the guest level.
> >
> > Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
> > ---
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++++
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 ++
> > 2 files changed, 6 insertions(+)
> >
> > 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 1f318b5e0921..ac63185ae268 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -277,6 +277,9 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent)
> > /* Cover the entire SID range */
> > cmd[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
> > break;
> > + case CMDQ_OP_TLBI_NH_VAA:
> > + ent->tlbi.asid = 0;
>
> This is backwards - NH_VA is a superset of NH_VAA (not to mention that
> quietly modifying the input argument is ugly; in fact it might be nice
> if ent was const here).
I see.
> Please follow the existing pattern, and decouple NH_VA from EL2_VA if
> necessary.
OK. I was trying to keep it neat, but it looks like decoupling
is the right way.
Thanks
Nic
Powered by blists - more mailing lists