Thanks a lot! It's much straightforward to me right now. One more thing, for the standard guest VM which uses EPT, What's the usage of "gfn" field in the "struct kvm_mmu_page"? Since it uses EPT, a single shadow page should has no relation with any of the guest physical page, right? According to the source code, each allocated shadow page "struct kvm_mmu_page" got it's gfn field filled. Thanks, Yaohui On Fri, Jun 19, 2015 at 11:23 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 19/06/2015 14:44, Hu Yaohui wrote: >> Hi Paolo, >> Thanks a lot! >> >> On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> >>> >>> On 19/06/2015 03:52, Hu Yaohui wrote: >>>> Hi All, >>>> In kernel 3.14.2, the kvm uses shadow EPT(EPT02) to implement the >>>> nested EPT. The shadow EPT(EPT02) is a shadow of guest EPT (EPT12). If >>>> the L1 guest writes to the guest EPT(EPT12). How can the shadow >>>> EPT(EPT02) be modified according? >>> >>> Because the EPT02 is write protected, writes to the EPT12 will trap to >>> the hypervisor. The hypervisor will execute the write instruction >>> before reentering the guest and invalidate the modified parts of the >>> EPT02. When the invalidated part of the EPT02 is accessed, the >>> hypervisor will rebuild it according to the EPT12 and the KVM memslots. >>> >> Do you mean EPT12 is write protected instead of EPT02? > > Yes, sorry. > >> According to my understanding, EPT12 will be write protected by marking the >> page table entry of EPT01 as readonly or marking the host page table >> entry as readonly. >> Could you please be more specific the code path which makes the >> corresponding page table entry as write protected? > > Look at set_spte's call to mmu_need_write_protect. > > Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in
