Hi Andres, On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote: >1. We were calling clear_flush_young_notify in unmap_one, but we are >within an mmu notifier invalidate range scope. The spte exists no more >(due to range_start) and the accessed bit info has already been >propagated (due to kvm_pfn_set_accessed). Simply call >clear_flush_young. > >2. We clear_flush_young on a primary MMU PMD, but this may be mapped >as a collection of PTEs by the secondary MMU (e.g. during log-dirty). >This required expanding the interface of the clear_flush_young mmu >notifier, so a lot of code has been trivially touched. > >3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate >the access bit by blowing the spte. This requires proper synchronizing >with MMU notifier consumers, like every other removal of spte's does. > [...] >--- >+ BUG_ON(!shadow_accessed_mask); > > for (sptep = rmap_get_first(*rmapp, &iter); sptep; > sptep = rmap_get_next(&iter)) { >+ struct kvm_mmu_page *sp; >+ gfn_t gfn; > BUG_ON(!is_shadow_present_pte(*sptep)); >+ /* From spte to gfn. */ >+ sp = page_header(__pa(sptep)); >+ gfn = kvm_mmu_page_get_gfn(sp, sptep - sp->spt); > > if (*sptep & shadow_accessed_mask) { > young = 1; > clear_bit((ffs(shadow_accessed_mask) - 1), > (unsigned long *)sptep); > } >+ trace_kvm_age_page(gfn, slot, young); IIUC, all the rmapps in this for loop are against the same gfn which results in the above trace point dump the message duplicated. Regards, Wanpeng Li -- 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