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

[David Hildenbrand]

On 26.02.20 17:06, Peter Xu wrote:
> 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>
> 

Thanks a lot!

BTW, while I am playing with userfaultfd, I already have patches to
factor out all uffd handling from postcopy code into utils/uffd.c

My list of patches does not seem to get any smaller :(

-- 
Thanks,

David / dhildenb