From mboxrd@z Thu Jan 1 00:00:00 1970 From: Davidlohr Bueso Subject: Re: KVM: MMU: Tracking guest writes through EPT entries ? Date: Thu, 30 Aug 2012 23:30:57 +0200 Message-ID: <1346362257.2747.19.camel@offbook> References: <501747A1.6000105@linux.vnet.ibm.com> Reply-To: dave@gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Xiao Guangrong , kvm@vger.kernel.org To: Sunil Agham Return-path: Received: from hapkido.dreamhost.com ([66.33.216.122]:59337 "EHLO hapkido.dreamhost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865Ab2H3Vbl (ORCPT ); Thu, 30 Aug 2012 17:31:41 -0400 Received: from homiemail-a10.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by hapkido.dreamhost.com (Postfix) with ESMTP id 8E16F18407 for ; Thu, 30 Aug 2012 14:31:41 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Tue, 2012-07-31 at 14:53 -0400, Sunil Agham wrote: > On Mon, Jul 30, 2012 at 10:49 PM, Xiao Guangrong > wrote: > > On 07/31/2012 01:18 AM, Sunil wrote: > >> Hello List, > >> > >> I am a KVM newbie and studying KVM mmu code. > >> > >> On the existing guest, I am trying to track all guest writes by > >> marking page table entry as read-only in EPT entry [ I am using Intel > >> machine with vmx and ept support ]. Looks like EPT support re-uses > >> shadow page table(SPT) code and hence some of SPT routines. > >> > >> I was thinking of below possible approach. Use pte_list_walk() to > >> traverse through list of sptes and use mmu_spte_update() to flip the > >> PT_WRITABLE_MASK flag. But all SPTEs are not part of any single list; > >> but on separate lists (based on gfn, page level, memory_slot). So, > >> recording all the faulted guest GFN and then using above method work ? > >> > > > > There are two ways to write-protect all sptes: > > - use kvm_mmu_slot_remove_write_access() on all memslots > > - walk the shadow page cache to get the shadow pages in the highest level > > (level = 4 on EPT), then write-protect its entries. > > > > If you just want to do it for the specified gfn, you can use > > rmap_write_protect(). > > > > Just inquisitive, what is your purpose? :) > > > > > Thanks Xiao ! > > Just hands on with virtualization hardware. Trying to preserve guest > state after migration. This is actually a very common technique for tracking guest pfn accesses -- triggering false page faults by write protecting the page tables. I used a similar approach to compute guest working sets and build miss rate curves. - Davidlohr