From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr54i-00030R-90 for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr54c-0002QP-Gb for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:08 -0400 Received: from smtp.aimale.com ([166.78.138.199]:50552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr54c-0002Q0-9K for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:02 -0400 References: <56250035.40805@aimale.com> <87twpkqyow.fsf@blackfin.pond.sub.org> <20151022191203.GC3736@thinpad.lan.raisama.net> <56293F99.1060109@aimale.com> <20151022214719.GD3736@thinpad.lan.raisama.net> <56295A60.1040901@aimale.com> <20151023185504.GI3736@thinpad.lan.raisama.net> <562A85C9.6050309@aimale.com> <87ziz60zeg.fsf@blackfin.pond.sub.org> <562E64C0.1080509@aimale.com> <20151026175217.GC4180@thinpad.lan.raisama.net> From: Valerio Aimale Message-ID: <562F8796.4070503@aimale.com> Date: Tue, 27 Oct 2015 08:17:58 -0600 MIME-Version: 1.0 In-Reply-To: <20151026175217.GC4180@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 Cc: qemu-devel@nongnu.org, Markus Armbruster , lcapitulino@redhat.com On 10/26/15 11:52 AM, Eduardo Habkost wrote: > > > I was trying to advocate the use of a shared mmap'ed region. The sharing > would be two-ways (RW for both) between the QEMU virtualizer and the libvmi > process. I envision that there could be a QEMU command line argument, such > as "--mmap-guest-memory " Understand that Eric feels strongly the > libvmi client should own the file name - I have not forgotten that. When > that command line argument is given, as part of the guest initialization, > QEMU creates a file of size equal to the size of the guest memory containing > all zeros, mmaps that file to the guest memory with PROT_READ|PROT_WRITE > and MAP_FILE|MAP_SHARED, then starts the guest. > This is basically what memory-backend-file (and the legacy -mem-path > option) already does today, but it unlinks the file just after opening > it. We can change it to accept a full filename and/or an option to make > it not unlink the file after opening it. > > I don't remember if memory-backend-file is usable without -numa, but we > could make it possible somehow. Eduardo, I did try this approach. It takes 2 line changes in exec.c: comment the unlink out, and making sure MAP_SHARED is used when -mem-path and -mem-prealloc are given. It works beautifully, and libvmi accesses are fast. However, the VM is slowed down to a crawl, obviously, because each RAM access by the VM triggers a page fault on the mmapped file. I don't think having a crawling VM is desirable, so this approach goes out the door. I think we're back at estimating the speed of other approaches as discussed previously: - via UNIX socket as per existing patch - via xp parsing the human readable xp output - via an xp-like command the returns memory content baseXX-encoded into a json string - via shared memory as per existing code and patch Any other?