qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]