From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XywYy-000700-40 for qemu-devel@nongnu.org; Thu, 11 Dec 2014 00:45:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XywYt-0006kB-34 for qemu-devel@nongnu.org; Thu, 11 Dec 2014 00:45:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XywYs-0006jo-S3 for qemu-devel@nongnu.org; Thu, 11 Dec 2014 00:45:15 -0500 Date: Thu, 11 Dec 2014 13:45:08 +0800 From: Fam Zheng Message-ID: <20141211054508.GA21182@ad.nay.redhat.com> References: <1417033667-10364-2-git-send-email-bdpayne@acm.org> <20141127020403.GA7921@fam-t430.nay.redhat.com> <874mtbdbov.fsf@blackfin.pond.sub.org> <87iohq4ha7.fsf@blackfin.pond.sub.org> <8761dm9o4t.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: "Bryan D. Payne" Cc: lcapitulino@redhat.com, Markus Armbruster , qemu-devel@nongnu.org On Wed, 12/10 21:33, Bryan D. Payne wrote: > > By "evidence", I mean actual numbers for actual QEMU code. Nothing > >> sophisticated, just use your new interface in a way you consider > >> relevant for your own use case, then approximate this use with existing > >> interfaces. The approximation can be very rough. For instance, showing > >> that doing the whole job with your approach is a much faster than doing > >> a necessary part of the job with existing commands would do. > >> > > > > Sure, I can put together some numbers to help with this discussion. > > > > I've done some performance testing on my laptop. I have setup LibVMI to > access KVM guest memory using one of three different options: > > QMP/pmemsave (dump bytes to a file and then read that back into memory) > HMC/xp command (dump bytes via human monitor command and repack the output > to binary form) > QMP/pmemaccess (access bytes through a Unix socket, this is the patch we > are discussing in this thread) > > For each of these I measured the time required to translate a guest kernel > virtual address into a guest physical address. This is done with a 64-bit > Ubuntu Trusty guest and the addresses are translated by walking the page > tables in the guest using the selected memory access technique. > > You can see the graph here: > http://cl.ly/image/322a3s0h1V05 > > For those that prefer text, here's the numbers (in microseconds): > QMP/pmemsave: 77706 > HMC/xp command: 92552 > QMP/pmemaccess: 95 > > As you can see, the technique proposed in this patch is about 3 orders of > magnitude faster than the options available in Qemu today. I will also > note that this is for a _single_ virtual address translation. A typical > introspection application will be doing much more work than this, which > will only compound the problem. > > Hopefully this helps to explain why I believe that this is an improvement > to the existing mechanisms. Please let me know if you have any questions > about these results. > > I'll continue some exploration of doing the pmemaccess bulk data transfer > over QMP, instead of the UNIX socket. And I'll report back here once I've > come up with some thoughts on the best way to proceed. > Look good. I believe QMP will be in between, and if it doesn't work as well, could you also try to use QEMU's char dev instead of limit this to unix socket? Fam