Thanks Paolo. Is there a way where reads would trap ? I explored a bit on PM_PRESENT_MASK. Though its not READ bit, but a PRESENT bit, it looks like it should generate traps on reads if this bit is reset. From code, looks like rmap_write_protect() like function I stated in previous mail should do. Would this approach work ? Are there any glaring problems with this approach ? -- Sunil On Mon, Sep 9, 2013 at 3:08 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 09/09/2013 11:45, Sunil ha scritto: >> Hello List, >> >> (1) What is the correct way of tracking reads on given gfn ? >> >> Looks like functions rmap_write_protect(kvm, gfn) and >> kvm_mmu_rmap_write_protect(kvm, gfn, slot) removes the write >> permission for the given page, by flipping write bit using >> PT_WRITABLE_MASK. Thus trapping writes. >> >> For trapping reads, are there similar routines ? If not, I see >> equivalent flag PM_PRESENT_MASK. Thus one way probably is writing >> wrapper routines similar to above to flip both read(present) and write >> bits. Or would it be just enough to drop the spte instead using >> function drop_spte() ? > > If you are using EPT and your processor has the accessed and dirty bits > for EPT page tables (cat /sys/module/kvm_intel/parameters/eptad), you > could use the accessed bit to track reads. They wouldn't trap, but you > would be able to poll the EPT page tables. > > Paolo > >> (2) Is kvm_flush_remote_tlbs() required after either of above approaches ? >> Is kvm_flush_remote_tlbs() correct function to flush tlbs ? >> >> -- >> -- >> 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 >> > > -- > 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 -- 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
