On 9/19/23 05:25, David Stevens wrote: > On Mon, Sep 18, 2023 at 6:53 PM Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote: >> >> On 9/11/23 05:16, David Stevens wrote: >>> --- a/arch/x86/kvm/mmu/paging_tmpl.h >>> +++ b/arch/x86/kvm/mmu/paging_tmpl.h >>> @@ -848,7 +848,8 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault >>> >>> out_unlock: >>> write_unlock(&vcpu->kvm->mmu_lock); >>> - kvm_release_pfn_clean(fault->pfn); >>> + if (fault->is_refcounted_page) >>> + kvm_set_page_accessed(pfn_to_page(fault->pfn)); >> >> The other similar occurrences in the code that replaced >> kvm_release_pfn_clean() with kvm_set_page_accessed() did it under the >> held mmu_lock. >> >> Does kvm_set_page_accessed() needs to be invoked under the lock? > > It looks like I made a mistake when folding the v8->v9 delta into the stack of > patches to get a clean v9 series. v8 of the series returned pfns without > reference counts from __kvm_follow_pfn, so the x86 MMU needed to mark the pages > as accessed under the lock. v9 instead returns pfns with a refcount (i.e. does > the same thing as __gfn_to_pfn_memslot), so the x86 MMU should instead call > kvm_release_page_clean outside of the lock. I've included the corrected version > of this patch in this email. [snip] I tested this series + the corrected version of the patch on Intel TGL using virgl/venus/virtio-intel on both qemu and crosvm on top of the recent linux-next. All is working good. Feel free to add my t-b to the v10: Tested-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> # virgl+venus+virtio-intel+i915 -- Best regards, Dmitry
