Re: [PATCH 3/4] KVM: MMU: track dirty page in speculative path properly

[Xiao Guangrong]

Marcelo Tosatti wrote:

>> How about just track access bit for speculative path, we set page both accessed and
>> dirty(if it's writable) only if the access bit is set?
> 
> A useful thing to do would be to allow read-only mappings, in the fault
> path (Lai sent a few patches in that direction sometime ago but there
> was no follow up).
> 
> So in the case of a read-only fault from the guest, you'd inform
> get_user_pages() that read-only access is acceptable (so swapcache pages
> can be mapped, or qemu can mprotect(PROT_READ) guest memory).
> 

Yeah, it's a great work, i guess Lai will post the new version soon.

And, even we do this, i think the page dirty track is still needed, right?
Then, how about my new idea to track page dirty for speculative path, just
as below draft patch does:

@@ -687,10 +687,11 @@ static void drop_spte(struct kvm *kvm, u64 *sptep, u64 new_spte)
        if (!is_rmap_spte(old_spte))
                return;
        pfn = spte_to_pfn(old_spte);
-       if (old_spte & shadow_accessed_mask)
+       if (old_spte & shadow_accessed_mask) {
                kvm_set_pfn_accessed(pfn);
-       if (is_writable_pte(old_spte))
-               kvm_set_pfn_dirty(pfn);
+               if (is_writable_pte(old_spte))
+                       kvm_set_pfn_dirty(pfn);
+       }
        rmap_remove(kvm, sptep);
 }
 
@@ -1920,8 +1921,11 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
         * demand paging).
         */
        spte = shadow_base_present_pte | shadow_dirty_mask;
-       if (!speculative)
+       if (!speculative) {
                spte |= shadow_accessed_mask;
+               if (is_writable_pte(*sptep))
+                       kvm_set_pfn_dirty(pfn);
+       }
        if (!dirty)
                pte_access &= ~ACC_WRITE_MASK;
        if (pte_access & ACC_EXEC_MASK)

It uses access bit to track both page accessed and page dirty, and it's rather cheap...



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/