[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240819184716.GT2032816@nvidia.com>
Date: Mon, 19 Aug 2024 15:47:16 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: kevin.tian@...el.com, will@...nel.org, joro@...tes.org,
suravee.suthikulpanit@....com, robin.murphy@....com,
dwmw2@...radead.org, baolu.lu@...ux.intel.com, shuah@...nel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v1 15/16] iommu/arm-smmu-v3: Add viommu cache
invalidation support
On Mon, Aug 19, 2024 at 11:38:22AM -0700, Nicolin Chen wrote:
> On Mon, Aug 19, 2024 at 03:28:11PM -0300, Jason Gunthorpe wrote:
> > On Mon, Aug 19, 2024 at 11:19:39AM -0700, Nicolin Chen wrote:
> >
> > > > But nesting enablment with out viommu is alot less useful than I had
> > > > thought :(
> > >
> > > Actually, without viommu, the hwpt cache invalidate alone could
> > > still support non-SVA case?
> >
> > That is what I thought, but doesn't the guest still have to invalidate
> > the CD table entry # 0?
>
> I recall it doesn't. The CD cache invalidation is required in the
> viommu invalidation for an SVA case where we need a PASID number
> to specify CD to the substream. But the CD to the default stream
> is only changed during a vSTE setup, and the host knows the PASID
> number (=0)?
I think that would subtly assume certain things about how the driver
does ordering, ie the that CD table entry 0 is setup with the S1
before we load it into the STE.
Yes, the Linux driver does that now, but I don't think anyone should
rely on that..
Jason
Powered by blists - more mailing lists