On Fri, Oct 23, 2015 at 08:35:15AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > 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. > > Valerio, would an command line option to share guest memory suffice, or > does it have to be a monitor command? If the latter, why?
IIUC, libvmi wants to be able to connect to arbitrary pre-existing running KVM instances on the host. As such I think it cannot assume anything about the way they have been started, so requiring they be booted with a special command line arg looks impractical for this scenario. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
