From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Correct way of tracking reads on given gfn ? Date: Mon, 9 Sep 2013 15:29:21 +0300 Message-ID: <20130909122921.GT17294@redhat.com> References: <522D9E00.3090806@redhat.com> <522DA88E.6060906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: SPA , "kvm@vger.kernel.org" To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60459 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751591Ab3IIM3Y (ORCPT ); Mon, 9 Sep 2013 08:29:24 -0400 Content-Disposition: inline In-Reply-To: <522DA88E.6060906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- Gleb.