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

[David Hildenbrand <david@redhat.com>]

On 26.02.20 17:26, Peter Xu wrote:
> On Wed, Feb 26, 2020 at 05:08:08PM +0100, David Hildenbrand wrote:
>> 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" <dgilbert@redhat.com>
>>>> Cc: Juan Quintela <quintela@redhat.com>
>>>> Cc: Peter Xu <peterx@redhat.com>
>>>> Cc: Andrea Arcangeli <aarcange@redhat.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>
>>> Reviewed-by: Peter Xu <peterx@redhat.com>
>>>
>>
>> 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 :(
> 
> Simply because you're working on more things? :)

virtio-mem has been a steady source of huge refactorings (both in QEMU
and the kernel). At least on the kernel side, an end might be in sight :)

> 
> Thanks for working on this (and this is far better than the exit()
> version, IMHO)!

Thanks for insisting to fix it instead of working around it!


-- 
Thanks,

David / dhildenb