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?
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'
}
