From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzH2c-0001Zi-9g for qemu-devel@nongnu.org; Thu, 11 Dec 2014 22:37:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzGve-0003Qz-Jx for qemu-devel@nongnu.org; Thu, 11 Dec 2014 22:30:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzGve-0003LG-2U for qemu-devel@nongnu.org; Thu, 11 Dec 2014 22:30:06 -0500 Date: Fri, 12 Dec 2014 11:29:55 +0800 From: Fam Zheng Message-ID: <20141212032955.GA808@ad.nay.redhat.com> References: <874mtbdbov.fsf@blackfin.pond.sub.org> <87iohq4ha7.fsf@blackfin.pond.sub.org> <8761dm9o4t.fsf@blackfin.pond.sub.org> <20141211054508.GA21182@ad.nay.redhat.com> 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: qemu-devel@nongnu.org, Markus Armbruster , lcapitulino@redhat.com On Thu, 12/11 20:28, Bryan D. Payne wrote: > > > > > For those that prefer text, here's the numbers (in microseconds): > > > QMP/pmemsave: 77706 > > > HMC/xp command: 92552 > > > QMP/pmemaccess: 95 > > > > I completed a proof of concept implementation for doing this memory access > completely over QMP. Basically, it works much like pmemsave except instead > of sending the data to a file it does a base64 encode and sends it back > over the QMP connection. Interestingly, my testing shows that this is > slightly slower than the pmemsave option. Running the same test as before > (virtual address translation), I get 88063 microsecs on average. So I > don't believe this option is viable. How did you setup your QMP, and how does the QMP transactions look like in your test? Is it Unix domain socket? If the # of requests are in a high rate, I think the overhead may come from QMP framework, mostly event loop synchronization: QMP messages are not processed if the device emulation code is running. Also did you try to compress the memory data with zlib, to compensate for the base64 encoding inflation? > > > 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? > > > I'm moving forward to try the Qemu chardev approach now. I haven't working > much with this construct before, so any pointers are appreciated. From > what I'm seeing, it looks like the user would create a chardev using one of > the QMP @chardev* commands? The schema doesn't indicate that these > commands return the chardev id, which seems odd as I was then assuming that > one could obtain the id and pass this into the pmemaccess QMP command. > Thoughts? The chardev will be assigned an "id" by user, as the paremeter of chardev-add, and later the user will pass id to pmemaccess. In pmemaccess implementation, we will find the chardev by qemu_chr_find, and read/write with qemu_chr_* functions. You can take examples from hw/char/* for devices' usage. Fam