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 <vale...@aimale.com> 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
