Skip to content
  • Paolo Bonzini's avatar
    kvm: introduce manual dirty log reprotect · 2a31b9db
    Paolo Bonzini authored
    
    
    There are two problems with KVM_GET_DIRTY_LOG.  First, and less important,
    it can take kvm->mmu_lock for an extended period of time.  Second, its user
    can actually see many false positives in some cases.  The latter is due
    to a benign race like this:
    
      1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
         them.
      2. The guest modifies the pages, causing them to be marked ditry.
      3. Userspace actually copies the pages.
      4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
         they were not written to since (3).
    
    This is especially a problem for large guests, where the time between
    (1) and (3) can be substantial.  This patch introduces a new
    capability which, when enabled, makes KVM_GET_DIRTY_LOG not
    write-protect the pages it returns.  Instead, userspace has to
    explicitly clear the dirty log bits just before using the content
    of the page.  The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
    64-page granularity rather than requiring to sync a full memslot;
    this way, the mmu_lock is taken for small amounts of time, and
    only a small amount of time will pass between write protection
    of pages and the sending of their content.
    
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    2a31b9db