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

[Eduardo Habkost]

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
> 
> does it make better sense now?

I think you are confused about what mmap() does. It will create a new
mapping into the process address space, containing the data from an
existing file, not the other way around.

-- 
Eduardo