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

[Valerio Aimale <valerio@aimale.com>]

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 <valerio@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?

qmp_pmemmap( [...]) {

     char *template = "/tmp/QEM_mmap_XXXXXXX";
     int mmap_fd;
     uint8_t *local_memspace = malloc( (size_t) 8589934592 /* assuming 
VM with 8GB RAM */);

     cpu_physical_memory_rw( (hwaddr) 0,  local_memspace , (hwaddr) 
8589934592 /* assuming VM with 8GB RAM */, 0 /* no write for now will 
discuss write later */);

    mmap_fd = mkstemp("/tmp/QEUM_mmap_XXXXXXX");

    mmap((void *) local_memspace, (size_t) 8589934592, PROT_READ | 
PROT_WRITE,  MAP_SHARED | MAP_ANON,  mmap_fd, (off_t) 0);

   /* etc */

}

pmemmap would return the following json

{
     'success' : 'true',
     'map_filename' : '/tmp/QEM_mmap_1234567'
}