On Thu, Jul 06, 2023 at 03:50:32PM -0700, Axel Rasmussen wrote: > The basic idea here is to "simulate" memory poisoning for VMs. A VM > running on some host might encounter a memory error, after which some > page(s) are poisoned (i.e., future accesses SIGBUS). They expect that > once poisoned, pages can never become "un-poisoned". So, when we live > migrate the VM, we need to preserve the poisoned status of these pages. > > When live migrating, we try to get the guest running on its new host as > quickly as possible. So, we start it running before all memory has been > copied, and before we're certain which pages should be poisoned or not. > > So the basic way to use this new feature is: > > - On the new host, the guest's memory is registered with userfaultfd, in > either MISSING or MINOR mode (doesn't really matter for this purpose). > - On any first access, we get a userfaultfd event. At this point we can > communicate with the old host to find out if the page was poisoned. > - If so, we can respond with a UFFDIO_POISON - this places a swap marker > so any future accesses will SIGBUS. Because the pte is now "present", > future accesses won't generate more userfaultfd events, they'll just > SIGBUS directly. > > UFFDIO_POISON does not handle unmapping previously-present PTEs. This > isn't needed, because during live migration we want to intercept > all accesses with userfaultfd (not just writes, so WP mode isn't useful > for this). So whether minor or missing mode is being used (or both), the > PTE won't be present in any case, so handling that case isn't needed. > > Similarly, UFFDIO_POISON won't replace existing PTE markers. This might > be okay to do, but it seems to be safer to just refuse to overwrite any > existing entry (like a UFFD_WP PTE marker). > > Signed-off-by: Axel Rasmussen <axelrasmussen@xxxxxxxxxx> I agree the current behavior is not as clear, especially after hwpoison introduced. uffdio-copy is special right now that it can overwrite a marker, so a buggy userapp can also overwrite a poisoned entry, but it also means the userapp is broken already, so may not really matter much. While zeropage wasn't doing that. I think that was just overlooked - i assume it has the same reasoning as uffdio-copy otherwise.. and no one just used zeropage over a wp marker yet, or just got it work-arounded by unprotect+zeropage. Not yet sure whether it'll make sense to unify this a bit, but making the new poison api to be strict look fine. If you have any thoughts after reading feel free to keep the discussion going, I can ack this one I think (besides my rename request in 1st patch): Acked-by: Peter Xu <peterx@xxxxxxxxxx> -- Peter Xu
