[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180315151645.fsgcywyawvtiwx52@lakrids.cambridge.arm.com>
Date: Thu, 15 Mar 2018 15:16:45 +0000
From: Mark Rutland <mark.rutland@....com>
To: Chintan Pandya <cpandya@...eaurora.org>
Cc: catalin.marinas@....com, will.deacon@....com, arnd@...db.de,
ard.biesheuvel@...aro.org, marc.zyngier@....com,
james.morse@....com, kristina.martsenko@....com,
takahiro.akashi@...aro.org, gregkh@...uxfoundation.org,
tglx@...utronix.de, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
akpm@...ux-foundation.org, toshi.kani@....com
Subject: Re: [PATCH v2 2/4] ioremap: Implement TLB_INV before huge mapping
On Thu, Mar 15, 2018 at 06:55:32PM +0530, Chintan Pandya wrote:
> On 3/15/2018 6:43 PM, Mark Rutland wrote:
> > On Thu, Mar 15, 2018 at 06:15:04PM +0530, Chintan Pandya wrote:
> > > Huge mapping changes PMD/PUD which could have
> > > valid previous entries. This requires proper
> > > TLB maintanance on some architectures, like
> > > ARM64.
> >
> > Just to check, I take it that you mean we could have a valid table
> > entry, but all the entries in that next level table must be invalid,
> > right?
>
> That was my assumption but my assumption can be wrong if any VA gets
> block mapping for 1G directly (instead of the 2M cases we discussed
> so far), then this would go for a toss.
Ok. Just considering the 4K -> 2M case, is that an assumption, or a
guarantee?
Thanks,
Mark.
Powered by blists - more mailing lists