From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: zhugh.fnst@cn.fujitsu.com, ehabkost@redhat.com, agraf@suse.de,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
imammedo@redhat.com, afaerber@suse.de,
david@gibson.dropbear.id.au
Subject: [Qemu-devel] [RFC v1 PATCH 0/3] cpus: Convert cpu_index into a bitmap
Date: Fri, 8 May 2015 15:21:33 +0530 [thread overview]
Message-ID: <1431078696-29519-1-git-send-email-bharata@linux.vnet.ibm.com> (raw)
This patch changes the way cpu_index is handed out to newly created
CPUs by tracking the allocted CPUs in a bitmap. More information and
the need for this patch is described in patch 2/3 of this series. These
generic changes are needed to support CPU hot plug/unplug on PowerPC.
cpu_index is allocated in cpu_exec_init() and freed (during CPU unplug) in
the newly added API cpu_exec_exit(). Currently all architectures call
cpu_exec_init() from instance_init and hence cpu_exec_exit() is called
from instance_finalize for all archs in this series.
Instead of adding instance_finalize to all archs, we could call
cpu_exec_exit() from the parent class (CPUClass.instance_finalize).
However archs like x86 and PowerPC want cpu_exec_init() to be moved to
realizefn from instance_init. Such movement will become easy with the
current approach. Eudardo's suggested alternative of making cpu_exec_exit()
idempotent
(http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg01241.html)
will also simplify this movement, but I think that would compilicate the
deallocation logic.
Another open question is about handling of holes correctly in the allocated
bitmap to support VM migration after CPU unplug. This was briefly discussed
here:
https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00560.html
Should cpu_exec_init() API support specifying of a particular cpu_index
in addition to returning the next available cpu_index by default ? I know
that QEMU cmdline semantics for CPU device add/delele haven't been defined
yet, but should we now make provision in cpu_exec_init() to allocate the
required cpu_index ?
Changes in v1
-------------
- Added Error argument to cpu_exec_init() so that it callers calling
it from realizefn can collect errors.
v0: https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg02950.html
Bharata B Rao (3):
cpus: Add Error argument to cpu_exec_init()
cpus: Convert cpu_index into a bitmap
ppc: Move cpu_exec_init() call to realize function
exec.c | 39 +++++++++++++++++++++++++++++++++++----
include/exec/exec-all.h | 2 +-
include/qom/cpu.h | 8 ++++++++
target-alpha/cpu.c | 8 +++++++-
target-arm/cpu.c | 3 ++-
target-cris/cpu.c | 8 +++++++-
target-i386/cpu.c | 8 +++++++-
target-lm32/cpu.c | 8 +++++++-
target-m68k/cpu.c | 8 +++++++-
target-microblaze/cpu.c | 8 +++++++-
target-mips/cpu.c | 8 +++++++-
target-moxie/cpu.c | 8 +++++++-
target-openrisc/cpu.c | 8 +++++++-
target-ppc/translate_init.c | 15 +++++++++++++--
target-s390x/cpu.c | 3 ++-
target-sh4/cpu.c | 8 +++++++-
target-sparc/cpu.c | 3 ++-
target-tricore/cpu.c | 7 ++++++-
target-unicore32/cpu.c | 8 +++++++-
target-xtensa/cpu.c | 8 +++++++-
20 files changed, 153 insertions(+), 23 deletions(-)
--
2.1.0
next reply other threads:[~2015-05-08 9:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 9:51 Bharata B Rao [this message]
2015-05-08 9:51 ` [Qemu-devel] [RFC v1 PATCH 1/3] cpus: Add Error argument to cpu_exec_init() Bharata B Rao
2015-05-11 16:04 ` Eduardo Habkost
2015-05-08 9:51 ` [Qemu-devel] [RFC v1 PATCH 2/3] cpus: Convert cpu_index into a bitmap Bharata B Rao
2015-05-08 14:55 ` Eduardo Habkost
2015-05-11 3:33 ` Bharata B Rao
2015-05-11 14:28 ` Eduardo Habkost
2015-05-08 14:57 ` Eduardo Habkost
2015-05-11 3:37 ` Bharata B Rao
2015-05-11 14:37 ` Eduardo Habkost
2015-05-08 9:51 ` [Qemu-devel] [RFC v1 PATCH 3/3] ppc: Move cpu_exec_init() call to realize function Bharata B Rao
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=1431078696-29519-1-git-send-email-bharata@linux.vnet.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhugh.fnst@cn.fujitsu.com \
/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).