Re: [PATCH v3 13/13] migration/ram: Tolerate partially changed mappings in postcopy code

[Peter Xu]

On Wed, Feb 26, 2020 at 04:53:04PM +0100, David Hildenbrand wrote:
> When we partially change mappings (esp., mmap over parts of an existing
> mmap like qemu_ram_remap() does) where we have a userfaultfd handler
> registered, the handler will implicitly be unregistered from the parts that
> changed.
> 
> Trying to place pages onto mappings where there is no longer a handler
> registered will fail. Let's make sure that any waiter is woken up - we
> have to do that manually.
> 
> Let's also document how UFFDIO_UNREGISTER will handle this scenario.
> 
> This is mainly a preparation for RAM blocks with resizable allcoations,
> where the mapping of the invalid RAM range will change. The source will
> keep sending pages that are outside of the new (shrunk) RAM size. We have
> to treat these pages like they would have been migrated, but can
> essentially simply drop the content (ignore the placement error).
> 
> Keep printing a warning when we hit EINVAL, to avoid hiding other
> (programming) issues. ENOENT is unique.
> 
> Cc: "Dr. David Alan Gilbert" <address@hidden>
> Cc: Juan Quintela <address@hidden>
> Cc: Peter Xu <address@hidden>
> Cc: Andrea Arcangeli <address@hidden>
> Signed-off-by: David Hildenbrand <address@hidden>

Reviewed-by: Peter Xu <address@hidden>

-- 
Peter Xu