Hello Sean, On Wed, Dec 14, 2022 at 2:12 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Dec 12, 2022, Lai Jiangshan wrote: > > From: Lai Jiangshan <jiangshan.ljs@xxxxxxxxxxxx> > > > > Sometimes when the guest updates its pagetable, it adds only new gptes > > to it without changing any existed one, so there is no point to update > > the sptes for these existed gptes. > > > > Also when the sptes for these unchanged gptes are updated, the AD > > bits are also removed since make_spte() is called with prefetch=true > > which might result unneeded TLB flushing. > > If either of the proposed changes is kept, please move this to a separate patch. > Skipping updates for PTEs with the same protections is separate logical change > from skipping updates when making the SPTE writable. > > Actually, can't we just pass @prefetch=false to make_spte()? FNAME(prefetch_invalid_gpte) > has already verified the Accessed bit is set in the GPTE, so at least for guest > correctness there's no need to access-track the SPTE. Host page aging is already > fuzzy so I don't think there are problems there. FNAME(prefetch_invalid_gpte) has already verified the Accessed bit is set in the GPTE and FNAME(protect_clean_gpte) has already verified the Dirty bit is set in the GPTE. These are only for guest AD bits. And I don't think it is a good idea to pass @prefetch=false to make_spte(), since the host might have cleared AD bit in the spte for aging or dirty-log, The AD bits in the spte are better to be kept as before. Though passing @prefetch=false would not cause any correctness problem in the view of maintaining guest AD bits. > > > Do nothing if the permissions are unchanged or only write-access is > > being added. > > I'm pretty sure skipping the "make writable" case is architecturally wrong. On a > #PF, any TLB entries for the faulting virtual address are required to be removed. > That means KVM _must_ refresh the SPTE if a vCPU takes a !WRITABLE fault on an > unsync page. E.g. see kvm_inject_emulated_page_fault(). I might misunderstand what you meant or I failed to connect it with the SDM properly. I think there is no #PF here. And even if the guest is requesting writable, the hypervisor is allowed to set it non-writable and prepared to handle it in the ensuing write-fault. Skipping to make it writable is a kind of lazy operation and considered to be "the hypervisor doesn't grant the writable permission for a period before next write-fault". Thanks Lai
