On Tue, Sep 10, 2013 at 09:12:11AM +0800, Arthur Chunqi Li wrote: > On Mon, Sep 9, 2013 at 8:29 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > > On Mon, Sep 09, 2013 at 12:53:02PM +0200, Paolo Bonzini wrote: > >> Il 09/09/2013 12:22, SPA ha scritto: > >> > 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 ? > >> > >> I cannot say right away. Another way could be to set reserved bits to > >> generate EPT misconfigurations. See ept_set_mmio_spte_mask and > >> is_mmio_spte. > >> > >> This would trap both reads and writes. > >> > > Dropping all sptes will also work, but trapping each read access will be dog slow. QEMU > > emulation will be much faster. > Hi Gleb, > I'm interested in this topic, what do you mean by QEMU emulation? Do > you mean the functions in arch/x86/kvm/emulate.c? In what scenario > will KVM call these functions? > No, I mean don't use KVM at all. -- Gleb. -- 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
