qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, thorsten.kohfeldt@gmx.de
Subject: [Qemu-devel] [PATCH 0/2] memory: Convert skip_dump to ram_device and avoid memcpy
Date: Mon, 24 Oct 2016 16:59:48 -0600	[thread overview]
Message-ID: <20161024224044.7168.64176.stgit@gimli.home> (raw)

As based on previous RFC:

https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg05183.html

TL;DR, this adds tracing, converts skip_dump to ram_device (named
after rom_device), adds full access widths, identifies ram_device
regions based on ops pointer.

Paolo had suggested converting "skip_dump" to "device_memory", but
"ram_device" seemed like a better fit, feel free to disagree.  It
also didn't feel right to set ram_device via a separate function,
because then we need to worry about all the ways in which a
MemoryRegion might be manipulated to make sure we only apply this
attribute to the kind we want.  Much easier to have a separate
constructor that does this, we're not flipping this on and off like
romd.

Also, I had trouble documenting why I only implemented dword access
as in the RFC, it just seemed like procrastination, so let's just
support full qword.  In fact, why even care about alignment, we
really want to perform the access as prescribed by the guest driver
and performed by the guest processor.  If the driver does an invalid
width or alignment, then so should we.  At least that's my theory.
Of course this means that xp in the monitor once again can't dump
RTL MMIO in more than 4-byte chunks, but that seems like an
operator issue.  Dumping memory via xp is just a tool and if we
apply the tool to do accesses that the device is not capable of,
that's not a problem with the tool.

This fixes what I believe to be the problem Thorsten has
identified with RTL assignment and hopefully he can add a
Tested-by once confirmed.  Thanks,

Alex

---

Alex Williamson (2):
      memory: Replace skip_dump flag with "ram_device"
      memory: Don't use memcpy for ram_device regions


 hw/vfio/common.c      |    9 ++----
 hw/vfio/spapr.c       |    2 +
 include/exec/memory.h |   46 +++++++++++++++++++----------
 memory.c              |   79 +++++++++++++++++++++++++++++++++++++++++++++++--
 memory_mapping.c      |    2 +
 trace-events          |    2 +
 6 files changed, 114 insertions(+), 26 deletions(-)

             reply	other threads:[~2016-10-24 22:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 22:59 Alex Williamson [this message]
2016-10-24 22:59 ` [Qemu-devel] [PATCH 1/2] memory: Replace skip_dump flag with "ram_device" Alex Williamson
2016-10-24 23:00 ` [Qemu-devel] [PATCH 2/2] memory: Don't use memcpy for ram_device regions Alex Williamson
2016-10-25 11:32   ` Paolo Bonzini

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=20161024224044.7168.64176.stgit@gimli.home \
    --to=alex.williamson@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thorsten.kohfeldt@gmx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).