On Fri, Sep 04, 2020 at 02:31:11PM +0300, Adalbert Lazăr wrote:
quoted
VMAs obtained by mmap()ing memory access fds mirror the contents of
the remote process address space within the specified range. Pages are
installed in the current process page tables at fault time and removed
by the mmu_interval_notifier invalidate callbck. No further memory
management is involved.
quoted
On attempts to access a hole, or if a mapping was removed by
PIDFD_MEM_UNMAP, or if the remote process address space was reaped
by
quoted
OOM, the remote mapping fault handler returns VM_FAULT_SIGBUS.
I still think anything along these lines needs to meet the XPMEM use cases as
well, we have to have more general solutions for such MM
stuff:
https://gitlab.com/hjelmn/xpmem
However, I think this fundamentally falls into some of the same bad direction
as xpmem.
I would much rather see this design copy & clone the VMA's than try to
mirror the PTEs inside the VMAs from the remote into a single giant VMA and
somehow split/mirror the VMA ops.
This design was made specifically for virtual machine introspection, where we
care more about the contents of the address space, rather than the remote VMAs
and their vmops. (Right now only anon pages can be mapped, but I guess
we can extend to pagecache pages as well.) I just used what seemed to be the
common denominator to all page-related operations: range invalidation.
This looks like a general solution.
IMO cloning a VMA in an address space that has a completely different layout
will present its own set of caveats: What happens if the VMA resizes/splits?
Can you replay all the remote VMA vmops on the clone VMA?
This is just too weird and fragile to be maintaible over a long term.
For instance, one of the major bugs in things like xpmem was that they are
incompatible with get_user_pages(), largely because of this issue.
We support get_user_pages(), that's how we integrate with KVM.
The difference is the page returned will not belong to the current process.
I feel like I said this already..
Jason