[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Mar 2021 11:49:24 +0000
From: Will Deacon <will@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Jia He <justin.he@....com>, kvmarm@...ts.cs.columbia.edu,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Catalin Marinas <catalin.marinas@....com>,
Gavin Shan <gshan@...hat.com>,
Yanan Wang <wangyanan55@...wei.com>,
Quentin Perret <qperret@...gle.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix unaligned addr case in mmu walking
On Wed, Mar 03, 2021 at 09:54:25AM +0000, Marc Zyngier wrote:
> Hi Jia,
>
> On Wed, 03 Mar 2021 02:42:25 +0000,
> Jia He <justin.he@....com> wrote:
> >
> > If the start addr is not aligned with the granule size of that level.
> > loop step size should be adjusted to boundary instead of simple
> > kvm_granual_size(level) increment. Otherwise, some mmu entries might miss
> > the chance to be walked through.
> > E.g. Assume the unmap range [data->addr, data->end] is
> > [0xff00ab2000,0xff00cb2000] in level 2 walking and NOT block mapping.
>
> When does this occur? Upgrade from page mappings to block? Swap out?
>
> > And the 1st part of that pmd entry is [0xff00ab2000,0xff00c00000]. The
> > pmd value is 0x83fbd2c1002 (not valid entry). In this case, data->addr
> > should be adjusted to 0xff00c00000 instead of 0xff00cb2000.
>
> Let me see if I understand this. Assuming 4k pages, the region
> described above spans *two* 2M entries:
>
> (a) ff00ab2000-ff00c00000, part of ff00a00000-ff00c00000
> (b) ff00c00000-ff00db2000, part of ff00c00000-ff00e00000
>
> (a) has no valid mapping, but (b) does. Because we fail to correctly
> align on a block boundary when skipping (a), we also skip (b), which
> is then left mapped.
>
> Did I get it right? If so, yes, this is... annoying.
>
> Understanding the circumstances this triggers in would be most
> interesting. This current code seems to assume that we get ranges
> aligned to mapping boundaries, but I seem to remember that the old
> code did use the stage2_*_addr_end() helpers to deal with this case.
>
> Will: I don't think things have changed in that respect, right?
We've maintained stage2_pgd_addr_end() for the top-level iterator, but
it looks like we're failing to do the rounding in __kvm_pgtable_visit()
when hitting a leaf entry, so the caller (__kvm_pgtable_walk()) will
terminate early.
I agree that it's annoying, as you'd have expected us to run into this
earlier on.
Will
Powered by blists - more mailing lists