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...@arm.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