commit b4310bc9cd455e5e9c5bcd0eb8c4ed5284e3e0db
author Ard Biesheuvel <ardb@google.com> Mon Oct 23 11:13:44 2023 +0200
committer Ard Biesheuvel <ardb@google.com> Thu Nov 09 16:23:19 2023 +0100
tree 81a4428d2050578fe825662ca8bed6c00f98a085
parent dc4733947181cf90503c0ce47602a34e6d9af8b5

Map DBM data region down to pages

The purpose of the DBM data region is to keep track of updates, and only
write back those regions that were actually modified by the program.
This is implemented either using hardware DBM (where the page table
walker updates the descriptor directly) or via the exception handler
that clears the READ_ONLY bit when taking a write permission fault on a
read-only region that has the DBM flag set.

Currently, the DBM mappings of data regions could consist of block
mappings, if the size and placement of the region permits it. This means
that any store to such a region will mark the entire 2 MB window as
dirty and subject to writeback, which defeats the purpose of dirty state
tracking.

It also creates potential problems with the updated behavior of
modify_range() in the aarch64_paging crate, which will split ranges
rather than hand out mutable references to live block descriptors to the
users of the API. This means that calling modify_range() on a live
translation could result in break-before-make (BBM) violations.

These problems all go away if we simply map the DBM regions down to
pages from the start. This way, modify_range() will never result in a
split, and updating the read-only attribute is always BBM safe. It also
ensure that the amount of data requiring writeback is minimized.

Test: build tested only
Change-Id: I212e39d4fbbd6a65fb1544df9590ca7d9afb8a14