All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: "Bryan D. Payne" <bdpayne@acm.org>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	lcapitulino@redhat.com
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	[thread overview]
Message-ID: <20141212032955.GA808@ad.nay.redhat.com> (raw)
In-Reply-To: <CAFpPvXBxq_O1L6KuGumRRFd6oZJfM+vaHmFsUrEs1EJJTSF4Kg@mail.gmail.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

  reply	other threads:[~2014-12-12  3:37 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26  8:41 [Qemu-devel] [PATCH 0/1] qmp: extend QMP to provide read/write access to physical memory Bryan D. Payne
2014-11-26  8:41 ` [Qemu-devel] [PATCH 1/1] " Bryan D. Payne
2014-11-26 15:16   ` Eric Blake
2014-11-26 20:27 ` [Qemu-devel] [PATCH v2] " Bryan D. Payne
2014-11-26 20:27   ` [Qemu-devel] [PATCH] " Bryan D. Payne
2014-11-27  2:04     ` Fam Zheng
2014-12-04  3:37       ` Bryan D. Payne
2014-12-04  4:57         ` Fam Zheng
2014-12-04  6:28           ` Bryan D. Payne
2014-12-04  7:38             ` Fam Zheng
2014-12-04 16:43               ` Bryan D. Payne
2014-12-05  1:20                 ` Fam Zheng
2014-12-04  9:08         ` Markus Armbruster
2014-12-04 16:49           ` Bryan D. Payne
2014-12-05  8:44             ` Markus Armbruster
2014-12-05 21:25               ` Bryan D. Payne
2014-12-08 15:06                 ` Markus Armbruster
2014-12-09 15:12                   ` Bryan D. Payne
2014-12-11  3:33                     ` Bryan D. Payne
2014-12-11  5:45                       ` Fam Zheng
2014-12-11  6:07                         ` Bryan D. Payne
2014-12-12  2:28                         ` Bryan D. Payne
2014-12-12  3:29                           ` Fam Zheng [this message]
2014-12-01 22:10     ` Eric Blake
2014-12-03 23:07       ` Bryan D. Payne
2014-12-04 15:08         ` Eric Blake
2014-12-04 16:50           ` Bryan D. Payne
2014-12-04 18:40           ` Bryan D. Payne
2014-12-04 22:43             ` Eric Blake
2014-12-01 22:12   ` [Qemu-devel] [PATCH v2] " Eric Blake
2014-12-02  4:36     ` Bryan D. Payne
2014-12-02  5:26       ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141212032955.GA808@ad.nay.redhat.com \
    --to=famz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bdpayne@acm.org \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.