From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwZbI-0007ID-SW for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:49:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwZbH-0000jH-VR for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:49:56 -0500 Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:46975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwZbH-0000j6-Nv for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:49:55 -0500 Received: by mail-wi0-f182.google.com with SMTP id h11so28573589wiw.3 for ; Thu, 04 Dec 2014 08:49:55 -0800 (PST) MIME-Version: 1.0 Sender: bdpayne@gmail.com In-Reply-To: <874mtbdbov.fsf@blackfin.pond.sub.org> References: <1416991272-10277-1-git-send-email-bdpayne@acm.org> <1417033667-10364-1-git-send-email-bdpayne@acm.org> <1417033667-10364-2-git-send-email-bdpayne@acm.org> <20141127020403.GA7921@fam-t430.nay.redhat.com> <874mtbdbov.fsf@blackfin.pond.sub.org> From: "Bryan D. Payne" Date: Thu, 4 Dec 2014 08:49:34 -0800 Message-ID: Content-Type: multipart/alternative; boundary=f46d043be030ef8d1f050966bf4b Subject: Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Fam Zheng , qemu-devel@nongnu.org, lcapitulino@redhat.com --f46d043be030ef8d1f050966bf4b Content-Type: text/plain; charset=UTF-8 > > Can you explain again why the existing commands to read guest memory > (from the top of my head: dump-guest-memory, memsave, pmemsave) are > insufficient? How does your solution improve on them? What exactly can > it do what these commands can't? What exactly can't it do what these > commands can? > > I feel we need to understand the answers to these questions to sensibly > evolve the API in this area. Certainly. The main issue with this series of commands is that they dump the memory to a file on disk. What I'm trying to facilitate here is an application that monitors the guest memory in real time while the guest is running (likely with brief pauses during memory analysis periods). Writing all of this data to disk, and then reading it back again for the analysis application is several orders of magnitude too slow for these types of applications. This new method that I'm proposing here keeps everything in memory, which makes it much faster. Tldr; existing solutions are suitable for forensic analysis, whereas I'm looking to solve the runtime analysis problem. -bryan --f46d043be030ef8d1f050966bf4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you explain again why the existing commands = to read guest memory
(from the top of my head: dump-guest-memory, memsave, pmemsave) are
insufficient?=C2=A0 How does your solution improve on them?=C2=A0 What exac= tly can
it do what these commands can't?=C2=A0 What exactly can't it do wha= t these
commands can?

I feel we need to understand the answers to these questions to sensibly
evolve the API in this area.

Certainly.=C2= =A0 The main issue with this series of commands is that they dump the memor= y to a file on disk.=C2=A0 What I'm trying to facilitate here is an app= lication that monitors the guest memory in real time while the guest is run= ning (likely with brief pauses during memory analysis periods).=C2=A0 Writi= ng all of this data to disk, and then reading it back again for the analysi= s application is several orders of magnitude too slow for these types of ap= plications.

This new method that I'm proposing= here keeps everything in memory, which makes it much faster.
Tldr; existing solutions are suitable for forensic analysis, wh= ereas I'm looking to solve the runtime analysis problem.

=
-bryan
=C2=A0
--f46d043be030ef8d1f050966bf4b--