On 25/07/2018 22:04, Andrea Arcangeli wrote: > > It may look like the uffd-wp model is wish-feature similar to an > optimization, but without the uffd-wp model when the WP fault is > triggered by kernel code, the sigsegv model falls apart and requires > all kind of ad-hoc changes just for this single feature. Plus uffd-wp > has other benefits: it makes it all reliable in terms of not > increasing the number of vmas in use during the snapshot. Finally it > makes it faster too with no mmap_sem for reading and no sigsegv > signals. > > The non cooperative features got merged first because there was much > activity on the kernel side on that front, but this is just an ideal > time to nail down the remaining issues in uffd-wp I think. That I > believe is time better spent than trying to emulate it with sigsegv > and changing all drivers to send new events down to qemu specific to > the sigsegv handling. We considered this before doing uffd for > postcopy too but overall it's unreliable and more work (no single > change was then needed to KVM code with uffd to handle postcopy and > here it should be the same).
I totally agree. The hard part in userfaultfd was the changes to the kernel get_user_pages API, but the payback was huge because _all_ kernel uses (KVM, vhost-net, syscalls, etc.) just work with userfaultfd. Going back to mprotect would be a huge mistake. Paolo
