On Wed, Apr 12, 2023 at 09:34:48PM +0000, Anish Moorthy wrote: > Upon receiving an annotated EFAULT, userspace may take appropriate > action to resolve the failed access. For instance, this might involve a > UFFDIO_CONTINUE or MADV_POPULATE_WRITE in the context of uffd-based live > migration postcopy. As implemented, I think it will be prohibitively expensive if not impossible for userspace to determine why KVM is returning EFAULT when KVM_CAP_ABSENT_MAPPING_FAULT is enabled, which means userspace can't decide the correct action to take (try to resolve or bail). Consider the direct_map() case in patch in PATCH 15. The only way to hit that condition is a logic bug in KVM or data corruption. There isn't really anything userspace can do to handle this situation, and it has no way to distinguish that from faults to due absent mappings. We could end up hitting cases where userspace loops forever doing KVM_RUN, EFAULT, UFFDIO_CONTINUE/MADV_POPULATE_WRITE, KVM_RUN, EFAULT... Maybe we should just change direct_map() to use KVM_BUG() and return something other than EFAULT. But the general problem still exists and even if we have confidence in all the current EFAULT sites, we don't have much protection against someone adding an EFAULT in the future that userspace can't handle.
