Add VM_GET_POPULATED_PAGES and the vm_get_populated_pages() libvmmapi
wrapper to report which pages of a range of guest RAM are populated,
that is, resident or stored in swap. A page that is not populated reads
as zeroes, so a caller can skip it instead of reading it.
bhyve's checkpoint code reads all guest memory, and a read of a page
that the guest never touched or that was discarded, for example by
virtio-balloon, allocates the page. Linux hosts avoid this cost through
a shared zero page, but FreeBSD allocates a page on any fault. The
query lets the checkpoint code skip such pages without modifying guest
memory, which matters because some devices keep writing to guest memory
during a checkpoint.
Accept page-aligned ranges of at most 1024 host pages within one
system-memory mapping and return a bitmap. Hold the memory-segment
shared lock to keep mappings stable, and look up resident pages and swap
blocks under the object read lock. A page in the object counts as
populated whatever its state, so a page in transit to or from swap is
never reported as unpopulated. The result is a snapshot that concurrent
accesses may invalidate.
Share range validation with VM_DISCARD_PAGES. Define the ioctl only on
amd64, the only platform with bhyve checkpoint support, and add it to
its libvmmapi Capsicum allowlist.
mincore(2) on bhyve's mapping cannot be used instead: with the default
vm.mincore_mapped setting it reports only pages mapped by the calling
process, not pages populated through the guest's nested page tables,
and it never reports pages in swap.
Sponsored by: The FreeBSD Foundation