From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpLzD-00045A-Jv for qemu-devel@nongnu.org; Thu, 22 Oct 2015 15:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpLzA-0000hC-To for qemu-devel@nongnu.org; Thu, 22 Oct 2015 15:57:19 -0400 Received: from smtp.aimale.com ([166.78.138.199]:50610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpLzA-0000gT-NT for qemu-devel@nongnu.org; Thu, 22 Oct 2015 15:57:16 -0400 References: <1444952643-5033-1-git-send-email-valerio@aimale.com> <87h9lrkz56.fsf@blackfin.pond.sub.org> <56210A17.6080401@aimale.com> <87io63xpke.fsf@blackfin.pond.sub.org> <56250035.40805@aimale.com> <87twpkqyow.fsf@blackfin.pond.sub.org> <20151022191203.GC3736@thinpad.lan.raisama.net> From: Valerio Aimale Message-ID: <56293F99.1060109@aimale.com> Date: Thu, 22 Oct 2015 13:57:13 -0600 MIME-Version: 1.0 In-Reply-To: <20151022191203.GC3736@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Markus Armbruster Cc: qemu-devel@nongnu.org, lcapitulino@redhat.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 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' }