From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
patches@linaro.org
Subject: [Qemu-devel] [PATCH 0/3] exec: Collect CPU's AddressSpace info into its own struct
Date: Fri, 3 Jul 2015 16:11:40 +0100 [thread overview]
Message-ID: <1435936303-15335-1-git-send-email-peter.maydell@linaro.org> (raw)
This patchset is a bit of groundwork heading in the direction
of supporting multiple AddressSpaces per CPU. It does actually
do something useful (handle a FIXME remark in tcg_commit()) so
I've put it out for that reason and for some early comments.
Patch 1 is just removing an unnecessary call to cpu_reload_memory_map()
to make the cleanup a bit easier.
Patch 2 is a comment change which I hope Paolo will review to tell
me if I've misunderstood things :-)
Patch 3 is the actual work here: we collect up the fields that
were directly in CPUState but relating to our one-and-only
AddressSpace, and put them in a new struct CPUAddressSpace
CPUState now has a pointer to an array of these (with only one
entry for now). The rearrangement lets us fix the tcg_commit()
FIXME remark by going directly to the affected CPUState from
the MemoryListener pointer rather than having to search all CPUs
for it.
CPUState::as remains, as a convenience pointer to the first
AddressSpace we know about for the benefit of all the targets
which only have one AS per CPU.
The plan here for where to go next is to support calling
tcg_cpu_address_space_init() more than once (in which case
it will add entries to the array), and then update the places
which currently hardcode cpu->cpu_ases[0] to pick the entry
in the array based on a target-cpu hook to convert MemoryAttributes
into an address space index.
I also need to think a bit harder about how KVM will fit into
this, and exactly where we call tcg_cpu_address_space_init().
(Current thought is that should be from the cpu object's
realize function, based on QOM properties for allowing the board
to register the AddressSpaces with the CPU.)
Peter Maydell (3):
exec.c: Don't call cpu_reload_memory_map() from cpu_exec_init()
cpu-exec.c: Clarify comment about cpu_reload_memory_map()'s RCU
operations
exec.c: Collect AddressSpace related fields into a CPUAddressSpace
struct
cpu-exec.c | 33 ++++++++++++++--------------
exec.c | 57 ++++++++++++++++++++++++++++++++-----------------
include/exec/exec-all.h | 2 +-
include/qemu/typedefs.h | 1 +
include/qom/cpu.h | 7 ++++--
5 files changed, 62 insertions(+), 38 deletions(-)
--
1.9.1
next reply other threads:[~2015-07-03 15:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-03 15:11 Peter Maydell [this message]
2015-07-03 15:11 ` [Qemu-devel] [PATCH 1/3] exec.c: Don't call cpu_reload_memory_map() from cpu_exec_init() Peter Maydell
2015-07-03 22:40 ` Edgar E. Iglesias
2015-07-03 15:11 ` [Qemu-devel] [PATCH 2/3] cpu-exec.c: Clarify comment about cpu_reload_memory_map()'s RCU operations Peter Maydell
2015-07-03 15:11 ` [Qemu-devel] [PATCH 3/3] exec.c: Collect AddressSpace related fields into a CPUAddressSpace struct Peter Maydell
2015-07-03 15:29 ` [Qemu-devel] [PATCH 0/3] exec: Collect CPU's AddressSpace info into its own struct Paolo Bonzini
2015-10-01 13:05 ` Peter Maydell
2015-10-01 13:34 ` 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=1435936303-15335-1-git-send-email-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=edgar.iglesias@gmail.com \
--cc=patches@linaro.org \
--cc=pbonzini@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 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).