[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 13/13] migration/ram: Tolerate partially changed mappings
From: |
Peter Xu |
Subject: |
Re: [PATCH v3 13/13] migration/ram: Tolerate partially changed mappings in postcopy code |
Date: |
Wed, 26 Feb 2020 11:26:30 -0500 |
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" <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 :(
Simply because you're working on more things? :)
Thanks for working on this (and this is far better than the exit()
version, IMHO)!
--
Peter Xu
- [PATCH v3 06/13] exec: Relax range check in ram_block_discard_range(), (continued)
- [PATCH v3 06/13] exec: Relax range check in ram_block_discard_range(), David Hildenbrand, 2020/02/26
- [PATCH v3 07/13] migration/ram: Discard RAM when growing RAM blocks after ram_postcopy_incoming_init(), David Hildenbrand, 2020/02/26
- [PATCH v3 08/13] migration/ram: Simplify host page handling in ram_load_postcopy(), David Hildenbrand, 2020/02/26
- [PATCH v3 09/13] migration/ram: Consolidate variable reset after placement in ram_load_postcopy(), David Hildenbrand, 2020/02/26
- [PATCH v3 10/13] migration/ram: Handle RAM block resizes during postcopy, David Hildenbrand, 2020/02/26
- [PATCH v3 11/13] migration/multifd: Print used_length of memory block, David Hildenbrand, 2020/02/26
- [PATCH v3 12/13] migration/ram: Use offset_in_ramblock() in range checks, David Hildenbrand, 2020/02/26
- [PATCH v3 13/13] migration/ram: Tolerate partially changed mappings in postcopy code, David Hildenbrand, 2020/02/26