Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi

[Eduardo Habkost]

On Fri, Oct 23, 2015 at 09:25:03AM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 22, 2015 at 03:51:28PM -0600, Valerio Aimale wrote:
> > On 10/22/15 3:47 PM, Eduardo Habkost wrote:
> > >On Thu, Oct 22, 2015 at 01:57:13PM -0600, Valerio Aimale wrote:
> > >>On 10/22/15 1:12 PM, Eduardo Habkost wrote:
> > >>>On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
> > >>>>Valerio Aimale <address@hidden> writes:
> > >>>[...]
> > >>>>>There's also a similar patch, floating around the internet, the uses
> > >>>>>shared memory, instead of sockets, as inter-process communication
> > >>>>>between libvmi and QEMU. I've never used that.
> > >>>>By the time you built a working IPC mechanism on top of shared memory,
> > >>>>you're often no better off than with AF_LOCAL sockets.
> > >>>>
> > >>>>Crazy idea: can we allocate guest memory in a way that support sharing
> > >>>>it with another process?  Eduardo, can -mem-path do such wild things?
> > >>>It can't today, but just because it creates a temporary file inside
> > >>>mem-path and unlinks it immediately after opening a file descriptor. We
> > >>>could make memory-backend-file also accept a full filename as argument,
> > >>>or add a mechanism to let QEMU send the open file descriptor to a QMP
> > >>>client.
> > >>>
> > >>Eduardo, would my "artisanal" idea of creating an mmap'ed image of the 
> > >>guest
> > >>memory footprint work, augmented by Eric's suggestion of having the qmp
> > >>client pass the filename?
> > >The code below doesn't make sense to me.
> > 
> > Ok. What I am trying to do is to create a mmapped() memory area of the guest
> > physical memory that can be shared between QEMU and an external process,
> > such that the external process can read arbitrary locations of the qemu
> > guest physical memory.
> > In short, I'm using mmap MAP_SHARED to share the guest memory area with a
> > process that is external to QEMU
> 
> I wonder if it is possible for you get access to the guest memory via
> sysfs instead, by simply accessing /proc/$PID/mem  avoiding the need for
> any special help from QEMU. /proc/$PID/maps can be used to find the
> offset of the guest memory region too, but looking for the map region
> that has the size that matches guest RAM size.

If libvmi needs to work with existing VMs (without reconfiguring and
restarting them), this may be the only way we could let it access guest
memory directly.

But I wouldn't trust the method of simply looking for the map region
that has the right size. This would be making many assumptions about how
exactly QEMU allocates guest RAM internally. Also, it would require
libvmi to ptrace-attach to QEMU first.

-- 
Eduardo