search for: vmf_insert_mix

On Fri, Nov 06, 2020 at 01:26:50PM -0800, Ralph Campbell wrote: > > On 11/6/20 12:03 AM, Christoph Hellwig wrote: >> I hate the extra pin count magic here. IMHO we really need to finish >> off the series to get rid of the extra references on the ZONE_DEVICE >> pages first. > > First, thanks for the review comments. > > I don't like the extra refcount

On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote: > ZONE_DEVICE struct pages have an extra reference count that complicates the > code for put_page() and several places in the kernel that need to check the > reference count to see that a page is not being used (gup, compaction, > migration, etc.). Clean up the code so the reference count doesn't need to > be

This is still an RFC because after looking at the pmem/dax code some more, I realized that the ZONE_DEVICE struct pages are being inserted into the process' page tables with vmf_insert_mixed() and a zero refcount on the ZONE_DEVICE struct page. This is sort of OK because insert_pfn() increments the reference count on the pgmap which is what prevents memunmap_pages() from freeing the struct pages and it doesn't check for a non-zero struct page reference count. But, any calls to ge...

...MEMORY_DEVICE_GENERIC: Struct pages are created in dev_dax_probe() and represent non-volatile memory. The device can be mmap()'ed which calls dax_mmap() which sets vma->vm_flags | VM_HUGEPAGE. A CPU page fault will result in a PTE, PMD, or PUD sized page (but not compound) to be inserted by vmf_insert_mixed() which will call either insert_pfn() or insert_page(). Neither insert_pfn() nor insert_page() increments the page reference count. Invalidations don't callback into the device driver so I don't see how page reference counts can be tracked without adding a mmu_interval_notifier. I think...

...MMU notifier update callbacks around the call to insert_pfn. >> >> Can't do that. >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() >> or vmf_insert_mixed(). > > Why would you need to target mmu notifier on target vma ? If the mapping of the source VMA changes, mirroring can update the target VMA via insert_pfn. But what ensures that KVM's MMU notifier dismantles its own existing page tables (so that they can be recreated with the new...

...MMU notifier update callbacks around the call to insert_pfn. >> >> Can't do that. >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() >> or vmf_insert_mixed(). > > Why would you need to target mmu notifier on target vma ? If the mapping of the source VMA changes, mirroring can update the target VMA via insert_pfn. But what ensures that KVM's MMU notifier dismantles its own existing page tables (so that they can be recreated with the new...

...oing. Everybody else uses PAGE_SHARED which should make the pte writeable immediately. Regards, Christian. > > However the most of drivers calling vmf_insert_pfn_prot do not > supply the 'pfn_mkwrite' callback so that the second fault is > unnecessary. > > So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, > we should also supply vmf_insert_pfn_mkwrite for drivers as well. > > Signed-off-by: Xianrong Zhou <Xianrong.Zhou at amd.com> > --- > arch/x86/entry/vdso/vma.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |...

...gt;>> >> >>>>> However the most of drivers calling vmf_insert_pfn_prot do not >> >>>>> supply the 'pfn_mkwrite' callback so that the second fault is >> unnecessary. >> >>>>> >> >>>>> So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, >> >>>>> we should also supply vmf_insert_pfn_mkwrite for drivers as well. >> >>>>> >> >>>>> Signed-off-by: Xianrong Zhou <Xianrong.Zhou at amd.com> >> >>>>> --- >> &...

...writeable >> immediately. >> >> Regards, >> Christian. >> >>> However the most of drivers calling vmf_insert_pfn_prot do not supply >>> the 'pfn_mkwrite' callback so that the second fault is unnecessary. >>> >>> So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we >>> should also supply vmf_insert_pfn_mkwrite for drivers as well. >>> >>> Signed-off-by: Xianrong Zhou <Xianrong.Zhou at amd.com> >>> --- >>> arch/x86/entry/vdso/vma.c | 3 ++- >>&g...

...t; Regards, >>>> Christian. >>>> >>>>> However the most of drivers calling vmf_insert_pfn_prot do not >>>>> supply the 'pfn_mkwrite' callback so that the second fault is unnecessary. >>>>> >>>>> So just like vmf_insert_mixed and vmf_insert_mixed_mkwrite pair, we >>>>> should also supply vmf_insert_pfn_mkwrite for drivers as well. >>>>> >>>>> Signed-off-by: Xianrong Zhou <Xianrong.Zhou at amd.com> >>>>> --- >>>>> arch/x86/entry/vdso/v...

...acks around the call to insert_pfn. > >> > >> Can't do that. > >> First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on > >> the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() > >> or vmf_insert_mixed(). > > > > Why would you need to target mmu notifier on target vma ? > > If the mapping of the source VMA changes, mirroring can update the > target VMA via insert_pfn. But what ensures that KVM's MMU notifier > dismantles its own existing page tables (so that they...

...; possible to call MMU notifier update callbacks around the call to insert_pfn. > > Can't do that. > First, insert_pfn() uses set_pte_at() which won't trigger the MMU notifier on > the target VMA. It's also static, so I'll have to access it thru vmf_insert_pfn() > or vmf_insert_mixed(). Why would you need to target mmu notifier on target vma ? You do not need that. The workflow is: userspace: ptr = mmap(/dev/kvm-mirroring-device, virtual_addresse_of_target) Then when the mirroring process access ptr it triggers page fault that endup in the vm_operation_struct-&...

From: Mircea C?rjaliu <mcirjaliu at bitdefender.com> The following two new mm exports are introduced: * mm_remote_map(struct mm_struct *req_mm, unsigned long req_hva, unsigned long map_hva) * mm_remote_unmap(unsigned long map_hva) * mm_remote_reset(void) * rmap_walk_remote(struct page *page, struct rmap_walk_control *rwc) This patch