On 05/11/2017 08:24 PM, Paolo Bonzini wrote:
On 11/05/2017 14:07, Zhoujian (jay) wrote:
- * Scan sptes if dirty logging has been stopped, dropping those
- * which can be collapsed into a single large-page spte. Later
- * page faults will create the large-page sptes.
+ * Reset each vcpu's mmu, then page faults will create the large-page
+ * sptes later.
*/
if ((change != KVM_MR_DELETE) &&
(old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
- !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
- kvm_mmu_zap_collapsible_sptes(kvm, new);
+ !(new->flags & KVM_MEM_LOG_DIRTY_PAGES)) {
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_mmu_reset_context(vcpu);
This should be "kvm_make_all_cpus_request(kvm, KVM_REQ_MMU_RELOAD);" but
I am not sure it is enough. I think that if you do not zap the SPTEs,
the page faults will use 4K SPTEs, not large ones (though I'd have to
check better; CCing Xiao and Wanpeng).
Yes, Paolo is right. kvm_mmu_reset_context() just reloads vCPU's
root page table, 4k mappings are still kept.
There are two issues reported:
- one is kvm_mmu_slot_apply_flags(), when enable dirty log tracking.
Its root cause is kvm_mmu_slot_remove_write_access() takes too much
time.
We can make the code adaptive to use the new fast-write-protect faculty
introduced by my patchset, i.e, if the number of pages contained in this
memslot is more than > TOTAL * FAST_WRITE_PROTECT_PAGE_PERCENTAGE, then
we use fast-write-protect instead.
- another one is kvm_mmu_zap_collapsible_sptes() when disable dirty
log tracking.
collapsible_sptes zaps 4k mappings to make memory-read happy, it is not
required by the semanteme of KVM_SET_USER_MEMORY_REGION and it is not
urgent for vCPU's running, it could be done in a separate thread and use
lock-break technology.