[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory |
Date: |
Fri, 12 Dec 2014 11:29:55 +0800 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, (continued)
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Markus Armbruster, 2014/12/04
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/04
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Markus Armbruster, 2014/12/05
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/05
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Markus Armbruster, 2014/12/08
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/09
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/10
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Fam Zheng, 2014/12/11
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/11
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory, Bryan D. Payne, 2014/12/11
- Re: [Qemu-devel] [PATCH] qmp: extend QMP to provide read/write access to physical memory,
Fam Zheng <=