> On 03/10/19 20:31, Jerome Glisse wrote: > > So in summary, the source qemu process has anonymous vma (regular libc > > malloc for instance). The introspector qemu process which mirror the > > the source qemu use mmap on /dev/kvm (assuming you can reuse the > kvm > > device file for this otherwise you can introduce a new kvm device > > file). > > It should be a new device, something like /dev/kvmmem. BitDefender's RFC > patches already have the right userspace API, that was not an issue. I get it so far. I have a patch that does mirroring in a separate VMA. We create an extra VMA with VM_PFNMAP/VM_MIXEDMAP that mirrors the source VMA in the other QEMU and is refreshed by the device MMU notifier. This is a simple choice for an introspector process that runs on the same host as the source QEMU. But how do I make the new VMA accessible as memory to the guest VM inside the introspector QEMU? I was thinking of 2 solutions: Create a new memslot based on the mirror VMA, hotplug it into the guest as new memory device (is this possible?) and have a guest-side driver allocate pages from that area. or Redirect (some) GFN->HVA translations into the new VMA based on a table of addresses required by the introspector process. Mircea
