migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots
commit6fee3a1fd9ecde99c43e659cf8eb6c35c116d05e
authorDavid Hildenbrand <david@redhat.com>
Mon, 11 Oct 2021 17:53:46 +0000 (11 19:53 +0200)
committerJuan Quintela <quintela@redhat.com>
Mon, 1 Nov 2021 21:56:44 +0000 (1 22:56 +0100)
treefed1863a2cb765f8f2add316977dbd8573226338
parentf7b9dcfbcf44aa38d132038e9b675ea7e714a570
migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots

We already don't ever migrate memory that corresponds to discarded ranges
as managed by a RamDiscardManager responsible for the mapped memory region
of the RAMBlock.

virtio-mem uses this mechanism to logically unplug parts of a RAMBlock.
Right now, we still populate zeropages for the whole usable part of the
RAMBlock, which is undesired because:

1. Even populating the shared zeropage will result in memory getting
   consumed for page tables.
2. Memory backends without a shared zeropage (like hugetlbfs and shmem)
   will populate an actual, fresh page, resulting in an unintended
   memory consumption.

Discarded ("logically unplugged") parts have to remain discarded. As
these pages are never part of the migration stream, there is no need to
track modifications via userfaultfd WP reliably for these parts.

Further, any writes to these ranges by the VM are invalid and the
behavior is undefined.

Note that Linux only supports userfaultfd WP on private anonymous memory
for now, which usually results in the shared zeropage getting populated.
The issue will become more relevant once userfaultfd WP supports shmem
and hugetlb.

Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
migration/ram.c