search for: insert_pfn

...>>>> Not sure i understand, you are saying that the solution i outline >>>> above does not work ? If so then i think you are wrong, in the above >>>> solution the importing process mmap a device file and the resulting >>>> vma is then populated using insert_pfn() and constantly keep >>>> synchronize with the target process through mirroring which means that >>>> you never have to look at the struct page ... you can mirror any kind >>>> of memory from the remote process. >>> >>> If insert_pfn in turn ca...

...>>>> Not sure i understand, you are saying that the solution i outline >>>> above does not work ? If so then i think you are wrong, in the above >>>> solution the importing process mmap a device file and the resulting >>>> vma is then populated using insert_pfn() and constantly keep >>>> synchronize with the target process through mirroring which means that >>>> you never have to look at the struct page ... you can mirror any kind >>>> of memory from the remote process. >>> >>> If insert_pfn in turn ca...

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> 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 mapping from the source VMA)? >> >> The KVM inspector process is also (or can be) a QEMU that will have to >> create...

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> 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 mapping from the source VMA)? >> >> The KVM inspector process is also (or can be) a QEMU that will have to >> create...

"Zhou, Xianrong" <Xianrong.Zhou at amd.com> writes: > [AMD Official Use Only - General] > >> >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >> >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not >> >>>>> make the pfn writable so the pte entry is normally read-only or >> >>>>> dirty catching. >> >>&...

...t; Not sure i understand, you are saying that the solution i outline > >>>> above does not work ? If so then i think you are wrong, in the above > >>>> solution the importing process mmap a device file and the resulting > >>>> vma is then populated using insert_pfn() and constantly keep > >>>> synchronize with the target process through mirroring which means that > >>>> you never have to look at the struct page ... you can mirror any kind > >>>> of memory from the remote process. > >>> > >>>...

...Oct 02, 2019 at 10:10:18PM +0200, Paolo Bonzini wrote: > On 02/10/19 19:04, Jerome Glisse wrote: > > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: > >>>> 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 mapping from the source VMA)? > >> > >> The KVM inspector process is also (or can be) a QEMU that will hav...

...e wrote: > > > Not sure i understand, you are saying that the solution i outline > > > above does not work ? If so then i think you are wrong, in the above > > > solution the importing process mmap a device file and the resulting > > > vma is then populated using insert_pfn() and constantly keep > > > synchronize with the target process through mirroring which means that > > > you never have to look at the struct page ... you can mirror any kind > > > of memory from the remote process. > > > > If insert_pfn in turn calls MMU not...

On 02/10/19 16:15, Jerome Glisse wrote: >>> 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 mapping from the source VMA)? >> > So just to make sure i follow we have: > - qemu process on host with anonymous vma >...

On 02/10/19 16:15, Jerome Glisse wrote: >>> 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 mapping from the source VMA)? >> > So just to make sure i follow we have: > - qemu process on host with anonymous vma >...

Am 23.01.24 um 09:33 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>> the pfn writable so the pte entry is normally read-only or dirty >>> catching. >> What? How do you got to this conclusion? > Sorry. I did n...

Am 24.01.24 um 03:43 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>>>> the pfn writable so the pte entry is normally read-only or dirty >>>>> catching. >>>> What? How do you got to this...

...cea CIRJALIU - MELIU wrote: > > On 03/10/19 17:42, Jerome Glisse wrote: > > > All that is needed is to make sure that vm_normal_page() will see > > > those pte (inside the process that is mirroring the other process) as > > > special which is the case either because insert_pfn() mark the pte as > > > special or the kvm device driver which control the vm_operation struct > > > set a > > > find_special_page() callback that always return NULL, or the vma has > > > either VM_PFNMAP or VM_MIXEDMAP set (which is the case with > > inser...

...________________ kernel messages: __________________________________________________________________________ Dec 29 09:30:47 toddb05 kernel: [78295.342497] BUG: unable to handle kernel paging request at ffff8800a3f93038 Dec 29 09:30:47 toddb05 kernel: [78295.342509] IP: [<ffffffff800efb69>] insert_pfn+0x139/0x1a0 Dec 29 09:30:47 toddb05 kernel: [78295.342523] PGD 2134067 PUD 2537067 PMD 2657067 PTE 80100000a3f93065 Dec 29 09:30:47 toddb05 kernel: [78295.342531] Oops: 0003 [#1] SMP Dec 29 09:30:47 toddb05 kernel: [78295.342537] last sysfs file: /sys/devices/xen-backend/vbd-2-768/statistics/wr_s...

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

Am 22.01.24 um 04:32 schrieb Xianrong Zhou: > The vmf_insert_pfn_prot could cause unnecessary double faults > on a device pfn. Because currently the vmf_insert_pfn_prot does > not make the pfn writable so the pte entry is normally read-only > or dirty catching. What? How do you got to this conclusion? > The first fault only sets up the pte entry wh...

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

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 get_page() will hit the VM_BUG_ON_PAGE() that checks for a reference count == 0. // mmap() an e...

...ctor process can be block through those call- backs > > (find_special_page() specificaly for which you have to return NULL all the > > time). > > > > To mirror target process memory you can use hmm_mirror, when you > > populate the inspector process page table you use insert_pfn() (mmap of > > the kvm device file must mark this vma as PFNMAP). > > > > By following the hmm_mirror API, anytime the target process has a change in > > its page table (ie virtual address -> page) you will get a callback and all you > > have to do is clear the pag...

...reated 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 just leaving the page reference count...