* Paolo Bonzini (pbonz...@redhat.com) wrote: > 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.
TBF I think Denis just wanted to get things moving, knowing that we've not got userfault-wp yet; what I'm curious about though is how Denis has anything stable given that the faults can land in syscalls and vhost etc. Dave > Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
