On Mon, May 16, 2022 at 2:06 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Fri, Apr 15, 2022, Lai Jiangshan wrote: > > From: Lai Jiangshan <jiangshan.ljs@xxxxxxxxxxxx> > > > > When NPT enabled L1 is PAE paging, vcpu->arch.mmu->get_pdptrs() which > > is nested_svm_get_tdp_pdptr() reads the guest NPT's PDPTE from memroy > > unconditionally for each call. > > > > The guest PAE root page is not write-protected. > > > > The mmu->get_pdptrs() in FNAME(walk_addr_generic) might get different > > values every time or it is different from the return value of > > mmu->get_pdptrs() in mmu_alloc_shadow_roots(). > > > > And it will cause FNAME(fetch) installs the spte in a wrong sp > > or links a sp to a wrong parent since FNAME(gpte_changed) can't > > check these kind of changes. > > > > Cache the PDPTEs and the problem is resolved. The guest is responsible > > to info the host if its PAE root page is updated which will cause > > nested vmexit and the host updates the cache when next nested run. > > Hmm, no, the guest is responsible for invalidating translations that can be > cached in the TLB, but the guest is not responsible for a full reload of PDPTEs. > Per the APM, the PDPTEs can be cached like regular PTEs: > > Under SVM, however, when the processor is in guest mode with PAE enabled, the > guest PDPT entries are not cached or validated at this point, but instead are > loaded and checked on demand in the normal course of address translation, just > like page directory and page table entries. Any reserved bit violations ared > etected at the point of use, and result in a page-fault (#PF) exception rather > than a general-protection (#GP) exception. This paragraph from the APM describes the behavior of CR3 loads while in SVM guest-mode. But this patch is changing how KVM emulates SVM host-mode (i.e. L1), right? It seems like AMD makes no guarantee whether or not CR3 loads pre-load PDPTEs while in SVM host-mode. (Although the APM does say that "modern processors" do not pre-load PDPTEs.) > > So if L1 modifies a PDPTE from !PRESENT (or RESERVED) to PRESENT (and valid), then > any active L2 vCPUs should recognize the new PDPTE without a nested VM-Exit because > the old entry can't have been cached in the TLB. > > In practice, snapshotting at nested VMRUN would likely work, but architecturally > it's wrong and could cause problems if L1+L2 are engange in paravirt shenanigans, > e.g. async #PF comes to mind. > > I believe the correct way to fix this is to write-protect nNPT PDPTEs like all other > shadow pages, which shouldn't be too awful to do as part of your series to route > PDPTEs through kvm_mmu_get_page().
