[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250304161943.GD5011@ziepe.ca>
Date: Tue, 4 Mar 2025 12:19:43 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Mikołaj Lenczewski <miko.lenczewski@....com>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
"suzuki.poulose@....com" <suzuki.poulose@....com>,
"yang@...amperecomputing.com" <yang@...amperecomputing.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>,
"joro@...tes.org" <joro@...tes.org>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"joey.gouly@....com" <joey.gouly@....com>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
"james.morse@....com" <james.morse@....com>,
"broonie@...nel.org" <broonie@...nel.org>,
"maz@...nel.org" <maz@...nel.org>,
"david@...hat.com" <david@...hat.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"nicolinc@...dia.com" <nicolinc@...dia.com>,
"mshavit@...gle.com" <mshavit@...gle.com>,
"jsnitsel@...hat.com" <jsnitsel@...hat.com>,
"smostafa@...gle.com" <smostafa@...gle.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v2 4/4] iommu/arm: Add BBM Level 2 smmu feature
On Tue, Mar 04, 2025 at 04:02:20PM +0000, Ryan Roberts wrote:
> On 04/03/2025 14:26, Jason Gunthorpe wrote:
> > On Mon, Mar 03, 2025 at 07:03:42PM +0000, Mikołaj Lenczewski wrote:
> >
> >> For example, if we use BBML2 for kernel mappings, does that require us
> >> to repaint all kernel mappings when disabling BBML2 on smmu attach? I
> >> am not sure, but definitely something to be worked out.
> >
> > No, it would be a per-mm_struct basis only if we did something like
> > that
> >
> > When the SMMU driver puts a SVA on top of the mm_struct it would
> > disable BBML2 usage only for that mm_struct and it's contained VMAs.
>
> I guess we would need to figure out some synchonization mechanism if disabling
> BBML2 dynaically per-mm. If there was already a BBML2 operation in flight would
> want to wait for it to end. But that's a problem to solve if/when it's shown to
> be needed, I think.
I have a feeling we can piggyback on the mmu notifiers to achieve this
as all the changes to the PTEs should be bracketed by notifier
callbacks..
Let's hope it isn't needed.
Jasob
Powered by blists - more mailing lists