> On 05/09/19 20:09, Jerome Glisse 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 notifiers for the target VMA (which would be > the KVM MMU notifier), then that would work. Though I guess it would be > 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(). Our model (the importing process is encapsulated in another VM) forces us to mirror certain pages from the anon VMA backing one VM's system RAM to the other VM's anon VMA. Using the functions above means setting VM_PFNMAP|VM_MIXEDMAP on the target anon VMA, but I guess this breaks the VMA. Is this recommended? Then, mapping anon pages from one VMA to another without fixing the refcount and the mapcount breaks the daemons that think they're working on a pure anon VMA (kcompactd, khugepaged). Mircea
