All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix <hugolin615@gmail.com>
To: kvm@vger.kernel.org
Subject: Re: KVM: MMU: Tracking guest writes through EPT entries ?
Date: Tue, 28 Aug 2012 03:30:13 +0000 (UTC)	[thread overview]
Message-ID: <loom.20120828T050655-538@post.gmane.org> (raw)
In-Reply-To: 501747A1.6000105@linux.vnet.ibm.com

Xiao Guangrong <xiaoguangrong <at> linux.vnet.ibm.com> writes:

> 
> 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? :)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
Hi, Guangrong, 

I have done similar things like Sunil did. Simply for study purpose. However, I 
found some very weird situations. Basically, in the guest vm, I allocate a chunk 
of memory (with size of a page) in a user level program. Through a guest kernel 
level module and my self defined hypercall, I pass the gva of this memory to 
kvm. Then I try different methods in the hypercall handler to write protect this 
page of memory. You can see that I want to write protect it through ETP instead 
of write protected in the guest page tables.  

1. I use kvm_mmu_gva_to_gpa_read to translate the gva into gpa. Based on the 
function, kvm_mmu_get_spte_hierarchy(vcpu, gpa, spte[4]), I change the codes to 
read sptep (the pointer to spte) instead of spte, so I can modify the spte 
corresponding to this gpa. What I observe is that if I modify spte[0] (I think 
this is the lowest level page table entry corresponding to EPT table; I can 
successfully modify it as the changes are reflected in the result of calling 
kvm_mmu_get_spte_hierarchy again), but my user level program in vm can still 
write to this page. 

In your this blog post, you mentioned (the shadow pages in the highest level 
(level = 4 on EPT)), I don't understand this part. Does this mean I have to 
modify spte[3] instead of spte[0]? I just try modify spte[1] and spte[3], both 
can cause vmexit. So I am totally confused about the meaning of level used in 
shadow page table and its relations to shadow page table. Can you help me to 
understand this?

2. As suggested by this post, I also use rmap_write_protect() to write protect 
this page. With kvm_mmu_get_spte_hierarchy(vcpu, gpa, spte[4]), I still can see 
that spte[0] gives me xxxxxx005 such result, this means that the function is 
called successfully. But still I can write to this page. 

I even try the function kvm_age_hva() to remove this spte, this gives me 0 of 
spte[0], but I still can write to this page. So I am further confused about the 
level used in the shadow page?

Really thanks and appreciate your reply. 

Felix





  parent reply	other threads:[~2012-08-28  3:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-30 17:18 KVM: MMU: Tracking guest writes through EPT entries ? Sunil
2012-07-31  2:49 ` Xiao Guangrong
2012-07-31 18:53   ` Sunil Agham
2012-08-30 21:30     ` Davidlohr Bueso
2012-08-28  3:30   ` Felix [this message]
2012-08-30 10:22     ` Xiao Guangrong
2012-08-30 18:59       ` Hugo
2012-08-31  2:54         ` Xiao Guangrong
2012-08-31 21:30           ` Hui Lin (Hugo) 
2012-09-02 13:29             ` Xiao Guangrong
     [not found]             ` <bb786815f6c14144acc31b8041486282@CITESHT1.ad.uillinois.edu>
2012-09-03  2:09               ` Hugo
2012-09-03  6:11                 ` Xiao Guangrong
2012-09-05  3:23                   ` Hugo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20120828T050655-538@post.gmane.org \
    --to=hugolin615@gmail.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.