From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXp67-0006mT-OS for qemu-devel@nongnu.org; Tue, 17 Mar 2015 06:51:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXp64-0005UE-H8 for qemu-devel@nongnu.org; Tue, 17 Mar 2015 06:51:43 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34874 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXp64-0005U1-3W for qemu-devel@nongnu.org; Tue, 17 Mar 2015 06:51:40 -0400 Message-ID: <55080738.2060705@suse.de> Date: Tue, 17 Mar 2015 11:51:36 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1426247796-1657-1-git-send-email-bharata@linux.vnet.ibm.com> In-Reply-To: <1426247796-1657-1-git-send-email-bharata@linux.vnet.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v0 PATCH] cpus: Convert cpu_index into a bitmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao , qemu-devel@nongnu.org Cc: imammedo@redhat.com, zhugh.fnst@cn.fujitsu.com, david@gibson.dropbear.id.au, agraf@suse.de, Bharata B Rao Am 13.03.2015 um 12:56 schrieb Bharata B Rao: > From: Bharata B Rao >=20 > Currently CPUState.cpu_index is monotonically increasing and a newly > created CPU always gets the next higher index. The next available > index is calculated by counting the existing number of CPUs. This is > fine as long as we only add CPUs, but there are architectures which > are starting to support CPU removal too. For an architecture like Power= PC > which derives its CPU identifier (device tree ID) from cpu_index, the > existing logic of generating cpu_index values causes problems. >=20 > With the currently proposed method of handling vCPU removal by parking > the vCPU fd in QEMU > (Ref: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02604.htm= l), > generating cpu_index this way will not work for PowerPC. >=20 > This patch changes the way cpu_index is handed out by maintaining > a bit map of the CPUs that tracks both addition and removal of CPUs. >=20 > I am not sure if this is the right and an acceptable approach. The > alternative is to do something similar for PowerPC alone and not > depend on cpu_index. >=20 > I have tested this with out-of-the-tree patches for CPU hot plug and > removal on x86 and sPAPR PowerPC. >=20 > Signed-off-by: Bharata B Rao > --- > exec.c | 39 +++++++++++++++++++++++++++++--------= -- > include/exec/exec-all.h | 1 + > target-alpha/cpu.c | 6 ++++++ > target-arm/cpu.c | 1 + > target-cris/cpu.c | 6 ++++++ > target-i386/cpu.c | 6 ++++++ > target-lm32/cpu.c | 6 ++++++ > target-m68k/cpu.c | 6 ++++++ > target-microblaze/cpu.c | 6 ++++++ > target-mips/cpu.c | 6 ++++++ > target-moxie/cpu.c | 6 ++++++ > target-openrisc/cpu.c | 6 ++++++ > target-ppc/translate_init.c | 6 ++++++ > target-s390x/cpu.c | 1 + > target-sh4/cpu.c | 6 ++++++ > target-sparc/cpu.c | 1 + > target-tricore/cpu.c | 5 +++++ > target-unicore32/cpu.c | 6 ++++++ > target-xtensa/cpu.c | 6 ++++++ > 19 files changed, 116 insertions(+), 10 deletions(-) >=20 > diff --git a/exec.c b/exec.c > index e97071a..7760f2d 100644 > --- a/exec.c > +++ b/exec.c > @@ -530,21 +530,40 @@ void tcg_cpu_address_space_init(CPUState *cpu, Ad= dressSpace *as) > } > #endif > =20 > +static DECLARE_BITMAP(cpu_index_map, MAX_CPUMASK_BITS); I don't see this constant being defined in this patch. How large is it? I wonder whether this might be stolen from an x86 ACPI/NUMA context and forced onto all architectures now? > + > +#ifdef CONFIG_USER_ONLY > +int max_cpus =3D 1; /* TODO: Check if this is correct ? */ This strikes me as wrong, as forking will create a copy of the initial CPUState, see cpu_copy(). The cpu_index might get overwritten inside the CPUState, not sure about that, but this here is global state. Can't we just keep the current code for CONFIG_USER_ONLY and skip all the bitmap functions? > +#endif > + > +static int cpu_get_free_index(void) > +{ > + int cpu =3D find_first_zero_bit(cpu_index_map, max_cpus); > + > + if (cpu =3D=3D max_cpus) { > + fprintf(stderr, "WARNING: qemu: Trying to use more " > + "CPUs than allowed max of %d\n", max_cpus); This is a bad API. :) If we can't handle it, use an Error** errp argument to pass that info outwards. Imagine this happening from QMP device-add, then this warning will go unnoticed on stderr. (Also, error_report() would use the real executable name.) > + return max_cpus; > + } else { > + bitmap_set(cpu_index_map, cpu, 1); > + return cpu; > + } > +} > + > +void cpu_exec_exit(CPUState *cpu) > +{ > + bitmap_clear(cpu_index_map, cpu->cpu_index, 1); > +} > + > void cpu_exec_init(CPUArchState *env) [snip] Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)