RE: DANGER WILL ROBINSON, DANGER

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux