All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: patches@linaro.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [Qemu-devel] [PATCH v2 for-4.0 0/3] Avoid cpu_physical_memory_read() in generic code
Date: Thu, 22 Nov 2018 17:26:50 +0000	[thread overview]
Message-ID: <20181122172653.3413-1-peter.maydell@linaro.org> (raw)

This patchset takes three places in generic code which
use cpu_physical_memory_read(), and changes them to use
address_space_read() instead.

Changes v1->v2:
 * patches 1, 2 unchanged (and reviewed)
 * patch 3: handle as being NULL (which for the
   load_elf APIs means "use address_space_memory")

cpu_physical_memory_{read,rw,write} all implicitly assume
that there is exactly one view of physical memory. This
is sort-of true today, but we'd like to be able to move
to having heterogenous systems where not all CPUs share
the same view of physical memory.

In disas.c we are disassembling for a particular CPU, so
use that CPU's primary address space (cs->as).

In monitor.c we are reading physical memory for a
particular CPU, so again use that CPU's primary address
space; we fall back to address_space_memory for the case
where there are no CPUs in the system (-machine none).

In elf_ops.h the function was passed an address space to
use, so just use it.

Other places in generic code that use these functions are:
 * dump.c -- the whole UI here seems to assume that there
   is only one view of memory and that is what is being dumped
 * cpu.c:qmp_pmemsave() -- again, the UI assumption is that
   there's only one view of memory
So I've left those alone.

NB: git grep command line for finding callsites:
 git grep '\<cpu_physical_memory_\(read\|write\|rw\)\>'

thanks
-- PMM


Peter Maydell (3):
  disas.c: Use address_space_read() to read memory
  monitor: Use address_space_read() to read memory
  elf_ops.h: Use address_space_write() to write memory

 include/hw/elf_ops.h | 4 +++-
 disas.c              | 5 ++++-
 monitor.c            | 8 +++++++-
 3 files changed, 14 insertions(+), 3 deletions(-)

-- 
2.19.1

             reply	other threads:[~2018-11-22 17:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 17:26 Peter Maydell [this message]
2018-11-22 17:26 ` [Qemu-devel] [PATCH v2 for-4.0 1/3] disas.c: Use address_space_read() to read memory Peter Maydell
2018-11-22 17:26 ` [Qemu-devel] [PATCH v2 for-4.0 2/3] monitor: " Peter Maydell
2018-11-22 22:30   ` Philippe Mathieu-Daudé
2018-11-22 17:26 ` [Qemu-devel] [PATCH v2 for-4.0 3/3] elf_ops.h: Use address_space_write() to write memory Peter Maydell
2018-11-22 22:28   ` Philippe Mathieu-Daudé
2018-12-14 11:30 ` [Qemu-devel] [PATCH v2 for-4.0 0/3] Avoid cpu_physical_memory_read() in generic code Peter Maydell

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=20181122172653.3413-1-peter.maydell@linaro.org \
    --to=peter.maydell@linaro.org \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=patches@linaro.org \
    --cc=philmd@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.