What about some editing of the big comment... /* * Currently, shadow PTEs are write protected in two cases, 1) write protecting * guest page tables, 2) resetting dirty tracking after KVM_GET_DIRTY_LOG. The * differences between these two sorts are: * * a) only the first case clears SPTE_MMU_WRITEABLE bit. * * b) the first case requires flushing the TLB immediately to avoid corruption * of the shadow page table on other VCPUs. In order to synchronize with * other VCPUs the flush is done under the MMU lock. * * The second case instead can delay flushing of the TLB until just before * returning the dirty bitmap is returned to userspace; this is because it * only write-protects pages that are set in the bitmap, and further writes * to those pages can be safely ignored until userspace examines the bitmap. * We rely on this to flush the TLB outside the MMU lock. * * A problem arises when these two cases occur concurrently. Userspace can * call KVM_GET_DIRTY_LOG, which write-protects pages but does not immediately * flush the TLB; in the meanwhile, KVM wants to write-protect a guest page * table, sees it's already write-protected, and the result is a corrupted TLB. * * To avoid this problem, when write protecting guest page tables we *always* * flush the TLB if the spte has the SPTE_MMU_WRITEABLE bit set, even if * the spte was already write-protected. This works since case 2 never touches * SPTE_MMU_WRITEABLE bit. In other words, whenever a spte is updated (only * permission and status bits are changed) we need to check whether a spte with * SPTE_MMU_WRITEABLE becomes readonly. If that happens, we flush the TLB. * mmu_spte_update() handles this. * * The rules to use SPTE_MMU_WRITEABLE and PT_WRITABLE_MASK are as follows: * * a) if you want to see if it has a writable TLB entry, or if the spte can be * writable on the mmu mapping, check SPTE_MMU_WRITEABLE. This is the most * common case, otherwise * * b) when fixing a page fault on the spte or doing write-protection for * dirty logging, check PT_WRITABLE_MASK. Is the above accurate? > * TODO: introduce APIs to split these two cases. What do you mean exactly? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
