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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>