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" <dgilb...@redhat.com> >>>> Cc: Juan Quintela <quint...@redhat.com> >>>> Cc: Peter Xu <pet...@redhat.com> >>>> Cc: Andrea Arcangeli <aarca...@redhat.com> >>>> Signed-off-by: David Hildenbrand <da...@redhat.com> >>> >>> Reviewed-by: Peter Xu <pet...@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
