On 7/30/21 10:52 AM, David Hildenbrand wrote:
> 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 <pet...@redhat.com>
> Signed-off-by: David Hildenbrand <da...@redhat.com>
> ---
> migration/ram.c | 53 +++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 01cea01774..fd5949734e 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -1639,6 +1639,28 @@ out:
> return ret;
> }
>
> +static inline void populate_range(RAMBlock *block, hwaddr offset, hwaddr
> size)
> +{
> + char *ptr = (char *) block->host;
> +
> + for (; offset < size; offset += qemu_real_host_page_size) {
> + char tmp = *(ptr + offset);
> +
> + /* Don't optimize the read out */
> + asm volatile("" : "+r" (tmp));
> + }
This template is now used 3 times, a good opportunity to extract it as
an (inline?) helper.
