Re: Nested EPT Write Protection

2015-06-22 Thread Paolo Bonzini


On 19/06/2015 20:57, Hu Yaohui wrote:
 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?

The gfn is the same value that you can find in bits 12 to MAXPHYADDR-1
of the EPT page table entry.

Paolo

 According to the source code, each allocated
 shadow page struct kvm_mmu_page got it's gfn field filled.
--
To unsubscribe from this list: send the line unsubscribe kvm in


Re: Nested EPT Write Protection

2015-06-22 Thread Paolo Bonzini


On 22/06/2015 15:28, Hu Yaohui wrote:
 
 */2504 pseudo_gfn = base_addr  PAGE_SHIFT;
 2505 sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
 2506   iterator.level - 1,
 2507   1, ACC_ALL, iterator.sptep);/*
 2508 if (!sp) {
 2509 pgprintk(nonpaging_map: ENOMEM\n);
 2510 kvm_release_pfn_clean(pfn);
 2511 return -ENOMEM;
 2512 }
.
 
 /code
 it will get a pseudo_gfn to allocate a kvm_mmu_page. What if a
 pseudo_gfn itself causes a tdp_page_fault?
 Will it make the corresponding EPT page table entry marked as readonly also?

If tdp_page_fault is used (meaning non-nested KVM: nested KVM uses
ept_page_fault instead), sp-unsync is always true:

/* in kvm_mmu_get_page - __direct_map passes direct == true */
if (!direct) {
if (rmap_write_protect(vcpu, gfn))
kvm_flush_remote_tlbs(vcpu-kvm);
if (level  PT_PAGE_TABLE_LEVEL  need_sync)
kvm_sync_pages(vcpu, gfn);

account_shadowed(vcpu-kvm, sp);
}

so mmu_need_write_protect always returns false.

Note that higher in kvm_mmu_get_page there is another conditional:

if (!need_sync  sp-unsync)
need_sync = true;

but it only applies to the !direct case.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in


Re: Nested EPT Write Protection

2015-06-19 Thread Hu Yaohui
Hi Paolo,
Thanks a lot!

On Fri, Jun 19, 2015 at 2:27 AM, Paolo Bonzini pbonz...@redhat.com 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?
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?

Thanks,
Yaohui
 Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in


Re: Nested EPT Write Protection

2015-06-19 Thread Paolo Bonzini


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.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Nested EPT Write Protection

2015-06-19 Thread Paolo Bonzini


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 pbonz...@redhat.com 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


Re: Nested EPT Write Protection

2015-06-19 Thread Hu Yaohui
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 pbonz...@redhat.com 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 pbonz...@redhat.com 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


Nested EPT Write Protection

2015-06-18 Thread Hu Yaohui
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?

Thanks,
Yaohui
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html