[{"id":1765110,"web_url":"http://patchwork.ozlabs.org/comment/1765110/","msgid":"<9b9d7198-2758-d9d7-df3b-1efab8a724f2@kaod.org>","list_archive_url":null,"date":"2017-09-08T06:38:29","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/06/2017 10:27 AM, Nikunj A Dadhania wrote:\n> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n> and smt threads.\n\nI think we could also use the '-numa' options to define the cpus\nper chip but this patch defines a good default layout and fixes \nan issue. \n\n> Signed-off-by: Nikunj A Dadhania \n\nReviewed-by: Cédric Le Goater \nTested-by: Cédric Le Goater \n\nI pushed the patch under the latest powernv tree :\n\n\thttps://github.com/legoater/qemu.git tags/powernv-2.10\n\nThanks,\n\nC.\n\n> ---\n> hw/ppc/pnv.c | 20 ++++++++++++++++++--\n> 1 file changed, 18 insertions(+), 2 deletions(-)\n> \n> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c\n> index 9724719..3fbaafb 100644\n> --- a/hw/ppc/pnv.c\n> +++ b/hw/ppc/pnv.c\n> @@ -642,7 +642,7 @@ static void ppc_powernv_init(MachineState *machine)\n> MemoryRegion *ram;\n> char *fw_filename;\n> long fw_size;\n> - int i;\n> + int i, cores_per_chip;\n> char *chip_typename;\n> PCIBus *pbus;\n> bool has_gfx = false;\n> @@ -710,6 +710,22 @@ static void ppc_powernv_init(MachineState *machine)\n> }\n> \n> pnv->chips = g_new0(PnvChip *, pnv->num_chips);\n> +\n> + /* If user has specified number of cores, use it. Otherwise, compute it. */\n> + if (smp_cores != 1) {\n> + cores_per_chip = smp_cores;\n> + } else {\n> + cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> + }\n> +\n> + if (smp_cpus != (smp_threads * pnv->num_chips * cores_per_chip)) {\n> + error_report(\"cpu topology not balanced: \"\n> + \"chips (%u) * cores (%u) * threads (%u) != \"\n> + \"number of cpus (%u)\",\n> + pnv->num_chips, cores_per_chip, smp_threads, smp_cpus);\n> + exit(1);\n> + }\n> +\n> for (i = 0; i < pnv->num_chips; i++) {\n> char chip_name[32];\n> Object *chip = object_new(chip_typename);\n> @@ -728,7 +744,7 @@ static void ppc_powernv_init(MachineState *machine)\n> object_property_add_child(OBJECT(pnv), chip_name, chip, &error_fatal);\n> object_property_set_int(chip, PNV_CHIP_HWID(i), \"chip-id\",\n> &error_fatal);\n> - object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> + object_property_set_int(chip, cores_per_chip, \"nr-cores\", &error_fatal);\n> object_property_set_int(chip, 1, \"num-phbs\", &error_fatal);\n> object_property_set_bool(chip, true, \"realized\", &error_fatal);\n> }\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpSN24g0Jz9t16\n\tfor ;\n\tFri, 8 Sep 2017 16:39:14 +1000 (AEST)","from localhost ([::1]:43559 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqCwa-000486-P1\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 02:39:12 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:45140)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqCw9-00047P-Sj\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 02:38:50 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqCw4-0008Oh-AH\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 02:38:45 -0400","from 8.mo4.mail-out.ovh.net ([188.165.33.112]:49294)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dqCw4-0008Nq-40\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 02:38:40 -0400","from player159.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo4.mail-out.ovh.net (Postfix) with ESMTP id CC9159527C\n\tfor ; Fri, 8 Sep 2017 08:38:36 +0200 (CEST)","from zorba.kaod.org (i15-les03-th2-31-37-69-229.sfr.lns.abo.bbox.fr\n\t[31.37.69.229]) (Authenticated sender: postmaster@kaod.org)\n\tby player159.ha.ovh.net (Postfix) with ESMTPSA id 64B2F480099;\n\tFri, 8 Sep 2017 08:38:29 +0200 (CEST)"],"To":"Nikunj A Dadhania , qemu-ppc@nongnu.org,\n\tdavid@gibson.dropbear.id.au","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"<9b9d7198-2758-d9d7-df3b-1efab8a724f2@kaod.org>","Date":"Fri, 8 Sep 2017 08:38:29 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-Ovh-Tracer-Id":"4245768550571477873","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrfeefgdduudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"188.165.33.112","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1765757,"web_url":"http://patchwork.ozlabs.org/comment/1765757/","msgid":"<20170909070212.GT2735@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-09T07:02:12","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Sep 06, 2017 at 01:57:48PM +0530, Nikunj A Dadhania wrote:\n> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n> and smt threads.\n> \n> Signed-off-by: Nikunj A Dadhania \n\nI don't understand why simply treating smp_cores as cores per chip is wrong.\n\n> ---\n> hw/ppc/pnv.c | 20 ++++++++++++++++++--\n> 1 file changed, 18 insertions(+), 2 deletions(-)\n> \n> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c\n> index 9724719..3fbaafb 100644\n> --- a/hw/ppc/pnv.c\n> +++ b/hw/ppc/pnv.c\n> @@ -642,7 +642,7 @@ static void ppc_powernv_init(MachineState *machine)\n> MemoryRegion *ram;\n> char *fw_filename;\n> long fw_size;\n> - int i;\n> + int i, cores_per_chip;\n> char *chip_typename;\n> PCIBus *pbus;\n> bool has_gfx = false;\n> @@ -710,6 +710,22 @@ static void ppc_powernv_init(MachineState *machine)\n> }\n> \n> pnv->chips = g_new0(PnvChip *, pnv->num_chips);\n> +\n> + /* If user has specified number of cores, use it. Otherwise, compute it. */\n> + if (smp_cores != 1) {\n> + cores_per_chip = smp_cores;\n> + } else {\n> + cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> + }\n> +\n> + if (smp_cpus != (smp_threads * pnv->num_chips * cores_per_chip)) {\n> + error_report(\"cpu topology not balanced: \"\n> + \"chips (%u) * cores (%u) * threads (%u) != \"\n> + \"number of cpus (%u)\",\n> + pnv->num_chips, cores_per_chip, smp_threads, smp_cpus);\n> + exit(1);\n> + }\n> +\n> for (i = 0; i < pnv->num_chips; i++) {\n> char chip_name[32];\n> Object *chip = object_new(chip_typename);\n> @@ -728,7 +744,7 @@ static void ppc_powernv_init(MachineState *machine)\n> object_property_add_child(OBJECT(pnv), chip_name, chip, &error_fatal);\n> object_property_set_int(chip, PNV_CHIP_HWID(i), \"chip-id\",\n> &error_fatal);\n> - object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> + object_property_set_int(chip, cores_per_chip, \"nr-cores\", &error_fatal);\n> object_property_set_int(chip, 1, \"num-phbs\", &error_fatal);\n> object_property_set_bool(chip, true, \"realized\", &error_fatal);\n> }","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"MnwixM++\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xq5Kn6mbtz9sCZ\n\tfor ;\n\tSat, 9 Sep 2017 17:24:29 +1000 (AEST)","from localhost ([::1]:48515 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqa7w-0000WV-2G\n\tfor incoming@patchwork.ozlabs.org; Sat, 09 Sep 2017 03:24:28 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:58748)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqa7K-0000Vo-Tc\n\tfor qemu-devel@nongnu.org; Sat, 09 Sep 2017 03:23:52 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqa7J-0005gD-T6\n\tfor qemu-devel@nongnu.org; Sat, 09 Sep 2017 03:23:50 -0400","from ozlabs.org ([2401:3900:2:1::2]:38805)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dqa7J-0005f5-4r; Sat, 09 Sep 2017 03:23:49 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xq5Jx19RKz9sCZ; Sat, 9 Sep 2017 17:23:45 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1504941825;\n\tbh=BqJVXmqhrV8fePWahj+dx55nsU3xSxAF/TJpYOJSb0Q=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=MnwixM++9y9fGkNzEKj3jEF08ckcIinYHF/UF6Sk8jO5vmOiErUgrSKBcGAwPikAG\n\tt3SoBD2zUF9QOgIFCgqkArTUBFkJeO5i1y0x3oT5dCJCOQf/3GE2OO5O4V7wnIRHjD\n\tmsB6UfBMvwYYyI4rNY/WE8HoaAawtYk2rl7eZ5B4=","Date":"Sat, 9 Sep 2017 17:02:12 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170909070212.GT2735@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"ScUgq5oMe+fJq4F1\"","Content-Disposition":"inline","In-Reply-To":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1766044,"web_url":"http://patchwork.ozlabs.org/comment/1766044/","msgid":"<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-11T05:10:10","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Wed, Sep 06, 2017 at 01:57:48PM +0530, Nikunj A Dadhania wrote:\n>> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n>> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n>> and smt threads.\n>> \n>> Signed-off-by: Nikunj A Dadhania \n>\n> I don't understand why simply treating smp_cores as cores per chip is wrong.\n\nWe do not have SMT support and when \"-smp 4\" is passed, smp_cores is\nalways set to 1. So only once core with one thread finally show up in\nthe guest. Moreover, I see spapr too doing similar thing in\nspapr_init_cpus() with boot_cores_nr.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrGGn6GdXz9s81\n\tfor ;\n\tMon, 11 Sep 2017 15:10:57 +1000 (AEST)","from localhost ([::1]:55478 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1drGzn-0004NB-V8\n\tfor incoming@patchwork.ozlabs.org; Mon, 11 Sep 2017 01:10:55 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36722)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1drGzO-0004MW-JX\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 01:10:31 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1drGzL-0004Rg-TU\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 01:10:30 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57340\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1drGzL-0004RC-OH\n\tfor qemu-devel@nongnu.org; Mon, 11 Sep 2017 01:10:27 -0400","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8B58n6C106035\n\tfor ; Mon, 11 Sep 2017 01:10:26 -0400","from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cw40pqs10-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 11 Sep 2017 01:10:26 -0400","from localhost\n\tby e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 11 Sep 2017 15:10:23 +1000","from d23relay07.au.ibm.com (202.81.31.226)\n\tby e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 11 Sep 2017 15:10:22 +1000","from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])\n\tby d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8B5ALQI41287844; Mon, 11 Sep 2017 15:10:21 +1000","from d23av01.au.ibm.com (localhost [127.0.0.1])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8B5ALca014632; Mon, 11 Sep 2017 15:10:22 +1000","from abhimanyu.vnet.linux.ibm.com (abhimanyu.in.ibm.com\n\t[9.124.35.97])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8B5ABD8014205\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Mon, 11 Sep 2017 15:10:19 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170909070212.GT2735@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>","Date":"Mon, 11 Sep 2017 10:40:10 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17091105-0048-0000-0000-0000025CC9F0","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091105-0049-0000-0000-00004812F4A7","Message-Id":"<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-11_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709110079","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1767630,"web_url":"http://patchwork.ozlabs.org/comment/1767630/","msgid":"<20170913073519.GK7550@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-13T07:35:19","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Mon, Sep 11, 2017 at 10:40:10AM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Wed, Sep 06, 2017 at 01:57:48PM +0530, Nikunj A Dadhania wrote:\n> >> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n> >> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n> >> and smt threads.\n> >> \n> >> Signed-off-by: Nikunj A Dadhania \n> >\n> > I don't understand why simply treating smp_cores as cores per chip is wrong.\n> \n> We do not have SMT support and when \"-smp 4\" is passed, smp_cores is\n> always set to 1. So only once core with one thread finally show up in\n> the guest. Moreover, I see spapr too doing similar thing in\n> spapr_init_cpus() with boot_cores_nr.\n\nI'm ok with adding an error if smp_threads > 1, since that won't\nwork. Breaking the identity that smp_cores is the number of cores per\nsocket (which should correspond to one chip) is not ok, though.\n\nI think you're misinterpreting the boot_cores_nr stuff - that's just\nabout translating the number of initially online vcpus into a number\nof initially online cores.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"pLylqHwZ\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsYPB4R87z9sNw\n\tfor ;\n\tWed, 13 Sep 2017 17:35:58 +1000 (AEST)","from localhost ([::1]:40618 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1ds2DE-0002Ec-GW\n\tfor incoming@patchwork.ozlabs.org; Wed, 13 Sep 2017 03:35:56 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:32969)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1ds2Co-0002EP-BG\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 03:35:31 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1ds2Cn-0000xK-8k\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 03:35:30 -0400","from ozlabs.org ([2401:3900:2:1::2]:44599)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1ds2Cm-0000rw-Ui; Wed, 13 Sep 2017 03:35:29 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xsYNX3cLqz9sPs; Wed, 13 Sep 2017 17:35:24 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505288124;\n\tbh=SQraTSuKrK0/HZJ3ti9W+PkV1L5ayFubSmfo2VVi1pI=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=pLylqHwZhSTE8Gh5a9v7+5iztjIam2TXP7jnKHVnMeCDbfFlkRdnHhTgYL7oWaz8i\n\tH3hvFUO675L0LoyimRU4KdKskL90XOe02gW1rwhkFZGpGBaB4EfgFUMoH0zjJwPPY0\n\t1n7UnQ7U89l5eml54yK8X4ji6B4EgMra9ERJKTjw=","Date":"Wed, 13 Sep 2017 17:35:19 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170913073519.GK7550@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"jITzwD3HDGXid3BE\"","Content-Disposition":"inline","In-Reply-To":"<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1768343,"web_url":"http://patchwork.ozlabs.org/comment/1768343/","msgid":"<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-14T05:12:52","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Mon, Sep 11, 2017 at 10:40:10AM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Wed, Sep 06, 2017 at 01:57:48PM +0530, Nikunj A Dadhania wrote:\n>> >> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n>> >> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n>> >> and smt threads.\n>> >> \n>> >> Signed-off-by: Nikunj A Dadhania \n>> >\n>> > I don't understand why simply treating smp_cores as cores per chip is wrong.\n>> \n>> We do not have SMT support and when \"-smp 4\" is passed, smp_cores is\n>> always set to 1. So only once core with one thread finally show up in\n>> the guest. Moreover, I see spapr too doing similar thing in\n>> spapr_init_cpus() with boot_cores_nr.\n>\n> I'm ok with adding an error if smp_threads > 1, since that won't\n> work. Breaking the identity that smp_cores is the number of cores per\n> socket (which should correspond to one chip) is not ok, though.\n>\n> I think you're misinterpreting the boot_cores_nr stuff - that's just\n> about translating the number of initially online vcpus into a number\n> of initially online cores.\n\nI thought, I am doing the same here for PowerNV, number of online cores\nis equal to initial online vcpus / threads per core\n\n int boot_cores_nr = smp_cpus / smp_threads;\n\nOnly difference that I see in PowerNV is that we have multiple chips\n(max 2, at the moment)\n\n cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n\nAnd in case user has provided sane smp_cores, we use it.\n\nRegards,\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xt6BY4xTFz9sPs\n\tfor ;\n\tThu, 14 Sep 2017 15:13:41 +1000 (AEST)","from localhost ([::1]:45794 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsMT5-0004vL-NG\n\tfor incoming@patchwork.ozlabs.org; Thu, 14 Sep 2017 01:13:39 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:39665)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsMSe-0004pl-0B\n\tfor qemu-devel@nongnu.org; Thu, 14 Sep 2017 01:13:13 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsMSa-0007ph-7A\n\tfor qemu-devel@nongnu.org; Thu, 14 Sep 2017 01:13:11 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46853)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dsMSZ-0007nl-Vg\n\tfor qemu-devel@nongnu.org; Thu, 14 Sep 2017 01:13:08 -0400","from pps.filterd (m0098396.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8E5BtUd006215\n\tfor ; Thu, 14 Sep 2017 01:13:06 -0400","from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cyj72bg1v-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 14 Sep 2017 01:13:05 -0400","from localhost\n\tby e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 14 Sep 2017 15:13:03 +1000","from d23relay06.au.ibm.com (202.81.31.225)\n\tby e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 14 Sep 2017 15:13:00 +1000","from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])\n\tby d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8E5D0RM38142148; Thu, 14 Sep 2017 15:13:00 +1000","from d23av02.au.ibm.com (localhost [127.0.0.1])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8E5Cob3027172; Thu, 14 Sep 2017 15:12:51 +1000","from abhimanyu.vnet.linux.ibm.com (abhimanyu.in.ibm.com\n\t[9.124.35.67])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8E5ChBQ027063\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Thu, 14 Sep 2017 15:12:48 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170913073519.GK7550@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>","Date":"Thu, 14 Sep 2017 10:42:52 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17091405-0004-0000-0000-0000022F060B","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091405-0005-0000-0000-00005E180C5A","Message-Id":"<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-13_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709140077","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1769021,"web_url":"http://patchwork.ozlabs.org/comment/1769021/","msgid":"<20170915064830.GI5250@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-15T06:48:30","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Thu, Sep 14, 2017 at 10:42:52AM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Mon, Sep 11, 2017 at 10:40:10AM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Wed, Sep 06, 2017 at 01:57:48PM +0530, Nikunj A Dadhania wrote:\n> >> >> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n> >> >> initialize 4 cpus. Compute the chip per cores depending on the number of chips\n> >> >> and smt threads.\n> >> >> \n> >> >> Signed-off-by: Nikunj A Dadhania \n> >> >\n> >> > I don't understand why simply treating smp_cores as cores per chip is wrong.\n> >> \n> >> We do not have SMT support and when \"-smp 4\" is passed, smp_cores is\n> >> always set to 1. So only once core with one thread finally show up in\n> >> the guest. Moreover, I see spapr too doing similar thing in\n> >> spapr_init_cpus() with boot_cores_nr.\n> >\n> > I'm ok with adding an error if smp_threads > 1, since that won't\n> > work. Breaking the identity that smp_cores is the number of cores per\n> > socket (which should correspond to one chip) is not ok, though.\n> >\n> > I think you're misinterpreting the boot_cores_nr stuff - that's just\n> > about translating the number of initially online vcpus into a number\n> > of initially online cores.\n> \n> I thought, I am doing the same here for PowerNV, number of online cores\n> is equal to initial online vcpus / threads per core\n> \n> int boot_cores_nr = smp_cpus / smp_threads;\n> \n> Only difference that I see in PowerNV is that we have multiple chips\n> (max 2, at the moment)\n> \n> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n\nThis doesn't make sense to me. Cores per chip should *always* equal\nsmp_cores, you shouldn't need another calculation for it.\n\n> And in case user has provided sane smp_cores, we use it.\n\nIf smp_cores isn't sane, you should simply reject it, not try to fix\nit. That's just asking for confusion.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"JIvNC5pY\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtpBd1VF6z9t2f\n\tfor ;\n\tFri, 15 Sep 2017 18:16:09 +1000 (AEST)","from localhost ([::1]:51869 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dslnD-0001Sm-73\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 04:16:07 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:58967)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dslmW-0001S2-2D\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:15:25 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dslmU-0004Rg-MV\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:15:24 -0400","from ozlabs.org ([2401:3900:2:1::2]:37365)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dslmU-0004PN-6C; Fri, 15 Sep 2017 04:15:22 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xtp9f1K78z9t2x; Fri, 15 Sep 2017 18:15:17 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505463318;\n\tbh=MEVA83BZmhDCugt8JWt2ZzMNEZLKHLPp5wvIvNaA1E4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=JIvNC5pYqK0w55cudGBZB7PztjJIB5uhGvtByL2ajGHtp1KZJJHbuMvzM4mZBORVl\n\tBMPIvspqamQnyr5BP1XxXakda2YGwHk1TOcbouPvizkhkXuLTAj10VxwJLCmXJJtxZ\n\tgJxfZBhHeYsJ+4eHl47GWP2hMd7AFt3adzs95IgU=","Date":"Fri, 15 Sep 2017 16:48:30 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170915064830.GI5250@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"a7XSrSxqzVsaECgU\"","Content-Disposition":"inline","In-Reply-To":"<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1769034,"web_url":"http://patchwork.ozlabs.org/comment/1769034/","msgid":"<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-15T08:23:15","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n>> \n>> I thought, I am doing the same here for PowerNV, number of online cores\n>> is equal to initial online vcpus / threads per core\n>> \n>> int boot_cores_nr = smp_cpus / smp_threads;\n>> \n>> Only difference that I see in PowerNV is that we have multiple chips\n>> (max 2, at the moment)\n>> \n>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>\n> This doesn't make sense to me. Cores per chip should *always* equal\n> smp_cores, you shouldn't need another calculation for it.\n>\n>> And in case user has provided sane smp_cores, we use it.\n>\n> If smp_cores isn't sane, you should simply reject it, not try to fix\n> it. That's just asking for confusion.\n\nThis is the case where the user does not provide a topology(which is a\nvalid scenario), not sure we should reject it. So qemu defaults\nsmp_cores/smt_threads to 1. I think it makes sense to over-ride.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtpMr3mtxz9sBZ\n\tfor ;\n\tFri, 15 Sep 2017 18:24:08 +1000 (AEST)","from localhost ([::1]:51907 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsluw-0008Kp-KW\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 04:24:06 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34201)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsluX-0008KF-Ne\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:23:42 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsluS-0001BS-Uc\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:23:41 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40689)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dsluS-0001B7-NF\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:23:36 -0400","from pps.filterd (m0098394.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8F8KaEM143331\n\tfor ; Fri, 15 Sep 2017 04:23:34 -0400","from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d06ffcpy6-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 15 Sep 2017 04:23:34 -0400","from localhost\n\tby e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 15 Sep 2017 18:23:32 +1000","from d23relay09.au.ibm.com (202.81.31.228)\n\tby e23smtp03.au.ibm.com (202.81.31.209) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 15 Sep 2017 18:23:30 +1000","from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])\n\tby d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8F8NTrY40173686; Fri, 15 Sep 2017 18:23:29 +1000","from d23av02.au.ibm.com (localhost [127.0.0.1])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8F8NJ9l001574; Fri, 15 Sep 2017 18:23:20 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.73.144])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8F8N7QX001284\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Fri, 15 Sep 2017 18:23:17 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170915064830.GI5250@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>","Date":"Fri, 15 Sep 2017 13:53:15 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17091508-0008-0000-0000-000001580B3A","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091508-0009-0000-0000-0000098D1511","Message-Id":"<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-15_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709150126","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1769058,"web_url":"http://patchwork.ozlabs.org/comment/1769058/","msgid":"<20170915085115.GN5250@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-15T08:51:15","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> >> \n> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> is equal to initial online vcpus / threads per core\n> >> \n> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> \n> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> (max 2, at the moment)\n> >> \n> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >\n> > This doesn't make sense to me. Cores per chip should *always* equal\n> > smp_cores, you shouldn't need another calculation for it.\n> >\n> >> And in case user has provided sane smp_cores, we use it.\n> >\n> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> > it. That's just asking for confusion.\n> \n> This is the case where the user does not provide a topology(which is a\n> valid scenario), not sure we should reject it. So qemu defaults\n> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n\nIf you can find a way to override it by altering smp_cores when it's\nnot explicitly specified, then ok.\n\nBut overriding smp_cores with a different variable that's the \"real\"\nnumber of cores is not acceptable. If that means the user has to\nspecify cores explicitly, so be it. Slight awkwardness in command\nline is preferable to breaking the assumption that smp_cores == (# of\ncores per next level up cpu object) which is used all over the place.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"pNz6xz+H\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtq7b2ylYz9sPr\n\tfor ;\n\tFri, 15 Sep 2017 18:58:35 +1000 (AEST)","from localhost ([::1]:52031 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsmSH-00089F-C5\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 04:58:33 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:44760)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsmRV-00083r-OO\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:57:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsmRS-0007xz-OY\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 04:57:45 -0400","from ozlabs.org ([103.22.144.67]:48761)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dsmRS-0007wL-68; Fri, 15 Sep 2017 04:57:42 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xtq6W4HT5z9sRm; Fri, 15 Sep 2017 18:57:39 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505465859;\n\tbh=K88+di/7uiTTXNgULToHm/jyUcUr6OjW/v1HzHvugAg=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=pNz6xz+HhRu+BLEgspvGFrl/Qwwzj9uLR8fHYE4RvL0VRzlPybg/01aXKVLokN9Lh\n\tBVab+7z2tcMIoTL9vIR/rHrvZSAso0+O33NbzGUYpR3+5MMn0+SAT9/KibOemTyMpG\n\thpltYEMHZDk/n2Wv6gMotkcorKMYIh6+znP21I4s=","Date":"Fri, 15 Sep 2017 18:51:15 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170915085115.GN5250@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"4Y142/9l9nQlBiaj\"","Content-Disposition":"inline","In-Reply-To":"<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"103.22.144.67","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1769064,"web_url":"http://patchwork.ozlabs.org/comment/1769064/","msgid":"<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-15T09:09:16","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> >> \n>> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> is equal to initial online vcpus / threads per core\n>> >> \n>> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> \n>> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> (max 2, at the moment)\n>> >> \n>> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >\n>> > This doesn't make sense to me. Cores per chip should *always* equal\n>> > smp_cores, you shouldn't need another calculation for it.\n>> >\n>> >> And in case user has provided sane smp_cores, we use it.\n>> >\n>> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> > it. That's just asking for confusion.\n>> \n>> This is the case where the user does not provide a topology(which is a\n>> valid scenario), not sure we should reject it. So qemu defaults\n>> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>\n> If you can find a way to override it by altering smp_cores when it's\n> not explicitly specified, then ok.\n\nShould I change the global smp_cores here as well ?\n\n> But overriding smp_cores with a different variable that's the \"real\"\n> number of cores is not acceptable. If that means the user has to\n> specify cores explicitly, so be it.\n\nRight, we would error out in case there is mismatch.\n\n> Slight awkwardness in command line is preferable to breaking the\n> assumption that smp_cores == (# of cores per next level up cpu object)\n> which is used all over the place.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtqSV46Thz9sPs\n\tfor ;\n\tFri, 15 Sep 2017 19:13:14 +1000 (AEST)","from localhost ([::1]:52146 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsmgS-0007IX-Ml\n\tfor incoming@patchwork.ozlabs.org; Fri, 15 Sep 2017 05:13:12 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:50413)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsmcy-0003wN-7T\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 05:09:37 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsmcu-0006iv-0i\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 05:09:36 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60335)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dsmct-0006ia-ON\n\tfor qemu-devel@nongnu.org; Fri, 15 Sep 2017 05:09:31 -0400","from pps.filterd (m0098399.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8F94QWN050454\n\tfor ; Fri, 15 Sep 2017 05:09:30 -0400","from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d084u284b-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 15 Sep 2017 05:09:30 -0400","from localhost\n\tby e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 15 Sep 2017 19:09:27 +1000","from d23relay06.au.ibm.com (202.81.31.225)\n\tby e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 15 Sep 2017 19:09:25 +1000","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8F99PXW18153636; Fri, 15 Sep 2017 19:09:25 +1000","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8F99H7f015977; Fri, 15 Sep 2017 19:09:17 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.73.144])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8F998qK015818\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Fri, 15 Sep 2017 19:09:14 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170915085115.GN5250@umbus.fritz.box>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>","Date":"Fri, 15 Sep 2017 14:39:16 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17091509-0012-0000-0000-0000025E0BF6","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091509-0013-0000-0000-0000077C176F","Message-Id":"<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-15_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709150136","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1770859,"web_url":"http://patchwork.ozlabs.org/comment/1770859/","msgid":"<20170919082421.GU27153@umbus>","list_archive_url":null,"date":"2017-09-19T08:24:21","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> >> \n> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> is equal to initial online vcpus / threads per core\n> >> >> \n> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> \n> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> (max 2, at the moment)\n> >> >> \n> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >\n> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >\n> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >\n> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> > it. That's just asking for confusion.\n> >> \n> >> This is the case where the user does not provide a topology(which is a\n> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >\n> > If you can find a way to override it by altering smp_cores when it's\n> > not explicitly specified, then ok.\n> \n> Should I change the global smp_cores here as well ?\n\nI'm pretty uneasy with that option. It would take a fair bit of\nchecking to ensure that changing smp_cores is safe here. An easier to\nverify option would be to make the generic logic which splits up an\nunspecified -smp N into cores and sockets more flexible, possibly\nbased on machine options for max values.\n\nThat might still be more trouble than its worth.\n\n> > But overriding smp_cores with a different variable that's the \"real\"\n> > number of cores is not acceptable. If that means the user has to\n> > specify cores explicitly, so be it.\n> \n> Right, we would error out in case there is mismatch.\n> \n> > Slight awkwardness in command line is preferable to breaking the\n> > assumption that smp_cores == (# of cores per next level up cpu object)\n> > which is used all over the place.\n> \n> Regards\n> Nikunj\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"e7uuVQPn\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxKWS61mvz9s7m\n\tfor ;\n\tTue, 19 Sep 2017 20:54:28 +1000 (AEST)","from localhost ([::1]:41446 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duGAc-000761-UP\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 06:54:26 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51329)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duFta-0001It-PB\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:57 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duFtX-0002yc-5v\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 06:36:50 -0400","from ozlabs.org ([103.22.144.67]:42283)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duFtW-0002tM-Ky; Tue, 19 Sep 2017 06:36:46 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxK6r0GHyz9t3V; Tue, 19 Sep 2017 20:36:34 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505817396;\n\tbh=LWOQ0xSl8tSBlcJXdovEN0QvjQA2+9kHHeUsPxKhtuo=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=e7uuVQPncq1IcL2ajjfXsTej4z9LdT/KYNg9nyQHsM4NUjNGcP20YmJH4BAKDIYSj\n\te55LnHoUOVqkxmXEGXNTxr+O0GOmtLOQ8tr1z5Cd5+Gt34ng2ghDIgNoYmpcH5TvMZ\n\t7dR49zt5PVr7+pA3cUp4ekg3XmIBDyk8tX4bRpu4=","Date":"Tue, 19 Sep 2017 18:24:21 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170919082421.GU27153@umbus>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"qgEfXXHyyarqcYJd\"","Content-Disposition":"inline","In-Reply-To":"<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"103.22.144.67","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771550,"web_url":"http://patchwork.ozlabs.org/comment/1771550/","msgid":"<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-20T04:20:24","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> >> David Gibson writes:\n>> >> \n>> >> >> \n>> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> >> is equal to initial online vcpus / threads per core\n>> >> >> \n>> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> >> \n>> >> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> >> (max 2, at the moment)\n>> >> >> \n>> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >> >\n>> >> > This doesn't make sense to me. Cores per chip should *always* equal\n>> >> > smp_cores, you shouldn't need another calculation for it.\n>> >> >\n>> >> >> And in case user has provided sane smp_cores, we use it.\n>> >> >\n>> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> >> > it. That's just asking for confusion.\n>> >> \n>> >> This is the case where the user does not provide a topology(which is a\n>> >> valid scenario), not sure we should reject it. So qemu defaults\n>> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>> >\n>> > If you can find a way to override it by altering smp_cores when it's\n>> > not explicitly specified, then ok.\n>> \n>> Should I change the global smp_cores here as well ?\n>\n> I'm pretty uneasy with that option.\n\nMe too.\n\n> It would take a fair bit of checking to ensure that changing smp_cores\n> is safe here. An easier to verify option would be to make the generic\n> logic which splits up an unspecified -smp N into cores and sockets\n> more flexible, possibly based on machine options for max values.\n>\n> That might still be more trouble than its worth.\n\nI think the current approach is the simplest and less intrusive, as we\nare handling a case where user has not bothered to provide a detailed\ntopology, the best we can do is create single threaded cores equal to\nnumber of cores.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxmlD5YK9z9sCZ\n\tfor ;\n\tWed, 20 Sep 2017 14:21:11 +1000 (AEST)","from localhost ([::1]:46602 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duWVY-0001Zz-AA\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 00:21:08 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:46442)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duWV7-0001Zb-Q0\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 00:20:42 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duWV4-0002Ox-Kq\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 00:20:41 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56926)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duWV4-0002Hh-C6\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 00:20:38 -0400","from pps.filterd (m0098404.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K4JHY3113957\n\tfor ; Wed, 20 Sep 2017 00:20:36 -0400","from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d3cmr6uxk-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 00:20:36 -0400","from localhost\n\tby e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 14:20:33 +1000","from d23relay09.au.ibm.com (202.81.31.228)\n\tby e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 14:20:32 +1000","from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])\n\tby d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8K4KW5341091296; Wed, 20 Sep 2017 14:20:32 +1000","from d23av02.au.ibm.com (localhost [127.0.0.1])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8K4KMJX007472; Wed, 20 Sep 2017 14:20:23 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.69.204])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8K4KFZ1007328\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Wed, 20 Sep 2017 14:20:20 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170919082421.GU27153@umbus>","References":"<20170906082748.28520-1-nikunj@linux.vnet.ibm.com>\n\t<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>","Date":"Wed, 20 Sep 2017 09:50:24 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092004-0048-0000-0000-0000025D7265","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092004-0049-0000-0000-000048143166","Message-Id":"<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200058","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771568,"web_url":"http://patchwork.ozlabs.org/comment/1771568/","msgid":"<20170920045524.GH5520@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-20T04:55:24","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> >> David Gibson writes:\n> >> >> \n> >> >> >> \n> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> >> is equal to initial online vcpus / threads per core\n> >> >> >> \n> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> >> \n> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> >> (max 2, at the moment)\n> >> >> >> \n> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >> >\n> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >> >\n> >> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >> >\n> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> >> > it. That's just asking for confusion.\n> >> >> \n> >> >> This is the case where the user does not provide a topology(which is a\n> >> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >> >\n> >> > If you can find a way to override it by altering smp_cores when it's\n> >> > not explicitly specified, then ok.\n> >> \n> >> Should I change the global smp_cores here as well ?\n> >\n> > I'm pretty uneasy with that option.\n> \n> Me too.\n> \n> > It would take a fair bit of checking to ensure that changing smp_cores\n> > is safe here. An easier to verify option would be to make the generic\n> > logic which splits up an unspecified -smp N into cores and sockets\n> > more flexible, possibly based on machine options for max values.\n> >\n> > That might still be more trouble than its worth.\n> \n> I think the current approach is the simplest and less intrusive, as we\n> are handling a case where user has not bothered to provide a detailed\n> topology, the best we can do is create single threaded cores equal to\n> number of cores.\n\nNo, sorry. Having smp_cores not correspond to the number of cores per\nchip in all cases is just not ok. Add an error message if the\ntopology isn't workable for powernv by all means. But users having to\nuse a longer command line is better than breaking basic assumptions\nabout what numbers reflect what topology.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"h/+/OaTc\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxnhr6mdPz9s82\n\tfor ;\n\tWed, 20 Sep 2017 15:04:12 +1000 (AEST)","from localhost ([::1]:46709 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duXBD-0003wP-34\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 01:04:11 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:42749)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duXAd-0003vT-Pj\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 01:03:37 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duXAc-0002dR-Cf\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 01:03:35 -0400","from ozlabs.org ([2401:3900:2:1::2]:57217)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duXAc-0002LD-06; Wed, 20 Sep 2017 01:03:34 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxnh11vF5z9s8J; Wed, 20 Sep 2017 15:03:29 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505883809;\n\tbh=hcgy6VqIEnykw7yATbRL0oLoqQYC16ajilfEpI3QdEc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=h/+/OaTcqj2Zfd1BcU4eZ6vPwSuEmGygy9mSsX1KSgNRxOjL3flj6QQtBkCvYn7tk\n\t582nKeQSEaCz6PGvsLuJD/IgH0/8KIW3woEoQbZxnyA2ulkQ4sNfD2uICDeWN7D0sn\n\tKVh7nxxkVX1y359eS7zFG6R1bzjkNwAjdXfTADJE=","Date":"Wed, 20 Sep 2017 14:55:24 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170920045524.GH5520@umbus.fritz.box>","References":"<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"Yia77v5a8fyVHJSl\"","Content-Disposition":"inline","In-Reply-To":"<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771572,"web_url":"http://patchwork.ozlabs.org/comment/1771572/","msgid":"<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-20T05:13:19","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>> >> David Gibson writes:\n>> >> \n>> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> >> >> David Gibson writes:\n>> >> >> \n>> >> >> >> \n>> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> >> >> is equal to initial online vcpus / threads per core\n>> >> >> >> \n>> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> >> >> \n>> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> >> >> (max 2, at the moment)\n>> >> >> >> \n>> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >> >> >\n>> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n>> >> >> > smp_cores, you shouldn't need another calculation for it.\n>> >> >> >\n>> >> >> >> And in case user has provided sane smp_cores, we use it.\n>> >> >> >\n>> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> >> >> > it. That's just asking for confusion.\n>> >> >> \n>> >> >> This is the case where the user does not provide a topology(which is a\n>> >> >> valid scenario), not sure we should reject it. So qemu defaults\n>> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>> >> >\n>> >> > If you can find a way to override it by altering smp_cores when it's\n>> >> > not explicitly specified, then ok.\n>> >> \n>> >> Should I change the global smp_cores here as well ?\n>> >\n>> > I'm pretty uneasy with that option.\n>> \n>> Me too.\n>> \n>> > It would take a fair bit of checking to ensure that changing smp_cores\n>> > is safe here. An easier to verify option would be to make the generic\n>> > logic which splits up an unspecified -smp N into cores and sockets\n>> > more flexible, possibly based on machine options for max values.\n>> >\n>> > That might still be more trouble than its worth.\n>> \n>> I think the current approach is the simplest and less intrusive, as we\n>> are handling a case where user has not bothered to provide a detailed\n>> topology, the best we can do is create single threaded cores equal to\n>> number of cores.\n>\n> No, sorry. Having smp_cores not correspond to the number of cores per\n> chip in all cases is just not ok. Add an error message if the\n> topology isn't workable for powernv by all means. But users having to\n> use a longer command line is better than breaking basic assumptions\n> about what numbers reflect what topology.\n\nSorry to ask again, as I am still not convinced, we do similar\nadjustment in spapr where the user did not provide the number of cores,\nbut qemu assumes them as single threaded cores and created\ncores(boot_cores_nr) that were not same as smp_cores ?\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxnwD4mmyz9s82\n\tfor ;\n\tWed, 20 Sep 2017 15:14:04 +1000 (AEST)","from localhost ([::1]:46740 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duXKk-0006JA-NN\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 01:14:02 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48618)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duXKO-0006I8-HO\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 01:13:42 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duXKN-0002eW-4e\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 01:13:40 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:43520)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duXKM-0002Wb-Rk\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 01:13:39 -0400","from pps.filterd (m0098399.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K58ftt098461\n\tfor ; Wed, 20 Sep 2017 01:13:38 -0400","from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d39dj3r4y-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 01:13:37 -0400","from localhost\n\tby e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 15:13:30 +1000","from d23relay07.au.ibm.com (202.81.31.226)\n\tby e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 15:13:28 +1000","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8K5DRgb40829104; Wed, 20 Sep 2017 15:13:27 +1000","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8K5DJMQ006902; Wed, 20 Sep 2017 15:13:20 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.69.204])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8K5DCVB006751\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Wed, 20 Sep 2017 15:13:17 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170920045524.GH5520@umbus.fritz.box>","References":"<20170909070212.GT2735@umbus.fritz.box>\n\t<87k2153jnx.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>","Date":"Wed, 20 Sep 2017 10:43:19 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092005-1617-0000-0000-000002002179","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092005-1618-0000-0000-0000484F696C","Message-Id":"<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200070","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771615,"web_url":"http://patchwork.ozlabs.org/comment/1771615/","msgid":"<20170920061756.GJ5520@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-20T06:17:56","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >> >> David Gibson writes:\n> >> >> \n> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> David Gibson writes:\n> >> >> >> \n> >> >> >> >> \n> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> >> >> is equal to initial online vcpus / threads per core\n> >> >> >> >> \n> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> >> >> \n> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> >> >> (max 2, at the moment)\n> >> >> >> >> \n> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >> >> >\n> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >> >> >\n> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >> >> >\n> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> >> >> > it. That's just asking for confusion.\n> >> >> >> \n> >> >> >> This is the case where the user does not provide a topology(which is a\n> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >> >> >\n> >> >> > If you can find a way to override it by altering smp_cores when it's\n> >> >> > not explicitly specified, then ok.\n> >> >> \n> >> >> Should I change the global smp_cores here as well ?\n> >> >\n> >> > I'm pretty uneasy with that option.\n> >> \n> >> Me too.\n> >> \n> >> > It would take a fair bit of checking to ensure that changing smp_cores\n> >> > is safe here. An easier to verify option would be to make the generic\n> >> > logic which splits up an unspecified -smp N into cores and sockets\n> >> > more flexible, possibly based on machine options for max values.\n> >> >\n> >> > That might still be more trouble than its worth.\n> >> \n> >> I think the current approach is the simplest and less intrusive, as we\n> >> are handling a case where user has not bothered to provide a detailed\n> >> topology, the best we can do is create single threaded cores equal to\n> >> number of cores.\n> >\n> > No, sorry. Having smp_cores not correspond to the number of cores per\n> > chip in all cases is just not ok. Add an error message if the\n> > topology isn't workable for powernv by all means. But users having to\n> > use a longer command line is better than breaking basic assumptions\n> > about what numbers reflect what topology.\n> \n> Sorry to ask again, as I am still not convinced, we do similar\n> adjustment in spapr where the user did not provide the number of cores,\n> but qemu assumes them as single threaded cores and created\n> cores(boot_cores_nr) that were not same as smp_cores ?\n\nWhat? boot_cores_nr has absolutely nothing to do with adjusting the\ntopology, and it certainly doesn't assume they're single threaded.\n\nboot_cores_nr is simply the number of cores (each of smp_threads\nthreads) which are online initially. In an sPAPR system there are\nmax_cpus total potential threads. Those are divided into cores each\nwith smp_threads threads (so max_cpus / smp_threads total cores), and\nthose cores are divided into sockets each with smp_cores sockets (so\nmax_cpus / smp_threads / smp_cores total sockets). Of all those\npotential threads smp_cpus are initially online (the rest can be\nhotplugged later), so there are smp_cpus / smp_threads cores initially\nonline.\n\nWe need that calculation because we can only hotplug cpus on spapr at\ncore granularity, not thread granularity (x86 can do that). If\nsmp_cpus is not a multiple of smp_threads we give an error (except for\nold machine types, where we have some hacks for backwards compat).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"dxni1sPJ\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxqd31q7qz9s7h\n\tfor ;\n\tWed, 20 Sep 2017 16:31:03 +1000 (AEST)","from localhost ([::1]:46967 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYXF-0000KB-Dz\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:31:01 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:43483)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYWn-0000K3-TV\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:30:35 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYWm-0001my-F9\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:30:33 -0400","from ozlabs.org ([2401:3900:2:1::2]:51999)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duYWm-0001OD-3K; Wed, 20 Sep 2017 02:30:32 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxqcN6Q0qz9sPs; Wed, 20 Sep 2017 16:30:28 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505889028;\n\tbh=29LZfABhXLc+0YsEbI6qdYeKRudWGCgxQ3FEsM0owHg=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=dxni1sPJ1EvbBiBWViORlTA2cMrdWZ8qQ24KB6Nk8srWsqWY2PIJv6TBjLoTrZ+sn\n\tV7/QvcHqXa5HQkpzvXwOEwGoKPD92DHtB0J33UxITdxPEX77ZhF1NBPWXPC/9fZcJ8\n\t8JjPSwL+mKeTvrZwHijfr31EhVCBj1zweTNVgLpk=","Date":"Wed, 20 Sep 2017 16:17:56 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170920061756.GJ5520@umbus.fritz.box>","References":"<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"dwWFXG4JqVa0wfCP\"","Content-Disposition":"inline","In-Reply-To":"<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771617,"web_url":"http://patchwork.ozlabs.org/comment/1771617/","msgid":"<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-20T06:40:48","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>> >> David Gibson writes:\n>> >> \n>> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>> >> >> David Gibson writes:\n>> >> >> \n>> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> David Gibson writes:\n>> >> >> >> \n>> >> >> >> >> \n>> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> >> >> >> is equal to initial online vcpus / threads per core\n>> >> >> >> >> \n>> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> >> >> >> \n>> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> >> >> >> (max 2, at the moment)\n>> >> >> >> >> \n>> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >> >> >> >\n>> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n>> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n>> >> >> >> >\n>> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n>> >> >> >> >\n>> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> >> >> >> > it. That's just asking for confusion.\n>> >> >> >> \n>> >> >> >> This is the case where the user does not provide a topology(which is a\n>> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n>> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>> >> >> >\n>> >> >> > If you can find a way to override it by altering smp_cores when it's\n>> >> >> > not explicitly specified, then ok.\n>> >> >> \n>> >> >> Should I change the global smp_cores here as well ?\n>> >> >\n>> >> > I'm pretty uneasy with that option.\n>> >> \n>> >> Me too.\n>> >> \n>> >> > It would take a fair bit of checking to ensure that changing smp_cores\n>> >> > is safe here. An easier to verify option would be to make the generic\n>> >> > logic which splits up an unspecified -smp N into cores and sockets\n>> >> > more flexible, possibly based on machine options for max values.\n>> >> >\n>> >> > That might still be more trouble than its worth.\n>> >> \n>> >> I think the current approach is the simplest and less intrusive, as we\n>> >> are handling a case where user has not bothered to provide a detailed\n>> >> topology, the best we can do is create single threaded cores equal to\n>> >> number of cores.\n>> >\n>> > No, sorry. Having smp_cores not correspond to the number of cores per\n>> > chip in all cases is just not ok. Add an error message if the\n>> > topology isn't workable for powernv by all means. But users having to\n>> > use a longer command line is better than breaking basic assumptions\n>> > about what numbers reflect what topology.\n>> \n>> Sorry to ask again, as I am still not convinced, we do similar\n>> adjustment in spapr where the user did not provide the number of cores,\n>> but qemu assumes them as single threaded cores and created\n>> cores(boot_cores_nr) that were not same as smp_cores ?\n>\n> What? boot_cores_nr has absolutely nothing to do with adjusting the\n> topology, and it certainly doesn't assume they're single threaded.\n\nWhen we start a TCG guest and user provides following commandline, e.g.\n\"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\nwith 4 cores, each having 1 thread.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxqsK3ksyz9s7f\n\tfor ;\n\tWed, 20 Sep 2017 16:41:41 +1000 (AEST)","from localhost ([::1]:47019 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYhX-00036K-KQ\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:41:39 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54510)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYh4-000362-CG\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:41:11 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYh0-000414-U3\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:41:10 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39214\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duYh0-00040d-Ow\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:41:06 -0400","from pps.filterd (m0098417.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K6dW7A019815\n\tfor ; Wed, 20 Sep 2017 02:41:06 -0400","from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d3brrqpuh-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 02:41:06 -0400","from localhost\n\tby e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 16:41:01 +1000","from d23relay08.au.ibm.com (202.81.31.227)\n\tby e23smtp07.au.ibm.com (202.81.31.204) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 16:40:59 +1000","from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138])\n\tby d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8K6exLd29294742; Wed, 20 Sep 2017 16:40:59 +1000","from d23av02.au.ibm.com (localhost [127.0.0.1])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8K6enNZ017154; Wed, 20 Sep 2017 16:40:50 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.69.204])\n\tby d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8K6eddY016963\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Wed, 20 Sep 2017 16:40:46 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170920061756.GJ5520@umbus.fritz.box>","References":"<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>","Date":"Wed, 20 Sep 2017 12:10:48 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092006-0044-0000-0000-00000287756F","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092006-0045-0000-0000-0000071D41DE","Message-Id":"<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200091","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771623,"web_url":"http://patchwork.ozlabs.org/comment/1771623/","msgid":"<87shfhhnhw.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-20T06:50:51","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"Nikunj A Dadhania writes:\n\n>> >> \n>>> >> I think the current approach is the simplest and less intrusive, as we\n>>> >> are handling a case where user has not bothered to provide a detailed\n>>> >> topology, the best we can do is create single threaded cores equal to\n>>> >> number of cores.\n>>> >\n>>> > No, sorry. Having smp_cores not correspond to the number of cores per\n>>> > chip in all cases is just not ok. Add an error message if the\n>>> > topology isn't workable for powernv by all means. But users having to\n>>> > use a longer command line is better than breaking basic assumptions\n>>> > about what numbers reflect what topology.\n>>> \n>>> Sorry to ask again, as I am still not convinced, we do similar\n>>> adjustment in spapr where the user did not provide the number of cores,\n>>> but qemu assumes them as single threaded cores and created\n>>> cores(boot_cores_nr) that were not same as smp_cores ?\n>>\n>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n>> topology, and it certainly doesn't assume they're single threaded.\n>\n> When we start a TCG guest and user provides following commandline,\n> e.g. \"-smp 4\", smt_threads is set to 1 by default in vl.c.\n\nI meant smp_threads here.\n\n> So the guest boots with 4 cores, each having 1 thread.\n>\n> Regards\n> Nikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxr4v2RV8z9s7h\n\tfor ;\n\tWed, 20 Sep 2017 16:51:43 +1000 (AEST)","from localhost ([::1]:47053 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYrF-0007uy-3F\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:51:41 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36106)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYqn-0007uO-3Y\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:51:14 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYqi-0006HD-49\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:51:13 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41020)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duYqh-0006GL-Sc\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:51:08 -0400","from pps.filterd (m0098404.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K6mwC3029110\n\tfor ; Wed, 20 Sep 2017 02:51:06 -0400","from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d3cmre1b8-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 02:51:06 -0400","from localhost\n\tby e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 16:51:04 +1000","from d23relay10.au.ibm.com (202.81.31.229)\n\tby e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 16:51:01 +1000","from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])\n\tby d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8K6p0iN38207640; Wed, 20 Sep 2017 16:51:00 +1000","from d23av04.au.ibm.com (localhost [127.0.0.1])\n\tby d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8K6p2h7031506; Wed, 20 Sep 2017 16:51:02 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.69.204])\n\tby d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8K6osrp031349\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Wed, 20 Sep 2017 16:50:59 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","References":"<20170913073519.GK7550@umbus.fritz.box>\n\t<8760clsw17.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","Date":"Wed, 20 Sep 2017 12:20:51 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092006-0048-0000-0000-0000025D74E5","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092006-0049-0000-0000-000048143599","Message-Id":"<87shfhhnhw.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200094","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771633,"web_url":"http://patchwork.ozlabs.org/comment/1771633/","msgid":"<20170920065700.GO5520@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-20T06:57:00","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> >> >> David Gibson writes:\n> >> >> \n> >> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> David Gibson writes:\n> >> >> >> \n> >> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> David Gibson writes:\n> >> >> >> >> \n> >> >> >> >> >> \n> >> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> >> >> >> is equal to initial online vcpus / threads per core\n> >> >> >> >> >> \n> >> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> >> >> >> \n> >> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> >> >> >> (max 2, at the moment)\n> >> >> >> >> >> \n> >> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >> >> >> >\n> >> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >> >> >> >\n> >> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >> >> >> >\n> >> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> >> >> >> > it. That's just asking for confusion.\n> >> >> >> >> \n> >> >> >> >> This is the case where the user does not provide a topology(which is a\n> >> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >> >> >> >\n> >> >> >> > If you can find a way to override it by altering smp_cores when it's\n> >> >> >> > not explicitly specified, then ok.\n> >> >> >> \n> >> >> >> Should I change the global smp_cores here as well ?\n> >> >> >\n> >> >> > I'm pretty uneasy with that option.\n> >> >> \n> >> >> Me too.\n> >> >> \n> >> >> > It would take a fair bit of checking to ensure that changing smp_cores\n> >> >> > is safe here. An easier to verify option would be to make the generic\n> >> >> > logic which splits up an unspecified -smp N into cores and sockets\n> >> >> > more flexible, possibly based on machine options for max values.\n> >> >> >\n> >> >> > That might still be more trouble than its worth.\n> >> >> \n> >> >> I think the current approach is the simplest and less intrusive, as we\n> >> >> are handling a case where user has not bothered to provide a detailed\n> >> >> topology, the best we can do is create single threaded cores equal to\n> >> >> number of cores.\n> >> >\n> >> > No, sorry. Having smp_cores not correspond to the number of cores per\n> >> > chip in all cases is just not ok. Add an error message if the\n> >> > topology isn't workable for powernv by all means. But users having to\n> >> > use a longer command line is better than breaking basic assumptions\n> >> > about what numbers reflect what topology.\n> >> \n> >> Sorry to ask again, as I am still not convinced, we do similar\n> >> adjustment in spapr where the user did not provide the number of cores,\n> >> but qemu assumes them as single threaded cores and created\n> >> cores(boot_cores_nr) that were not same as smp_cores ?\n> >\n> > What? boot_cores_nr has absolutely nothing to do with adjusting the\n> > topology, and it certainly doesn't assume they're single threaded.\n> \n> When we start a TCG guest and user provides following commandline, e.g.\n> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> with 4 cores, each having 1 thread.\n\nOk.. and what's the problem with that behaviour on powernv?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"htNj+K4k\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxrF14F4yz9s7h\n\tfor ;\n\tWed, 20 Sep 2017 16:58:45 +1000 (AEST)","from localhost ([::1]:47082 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYy3-0002eB-AZ\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:58:43 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:43407)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYxX-0002ci-V8\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:58:15 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYxW-0004jV-Ii\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:58:12 -0400","from ozlabs.org ([2401:3900:2:1::2]:54889)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duYxW-0004hg-7p; Wed, 20 Sep 2017 02:58:10 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxrDH5x6zz9s8J; Wed, 20 Sep 2017 16:58:07 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505890687;\n\tbh=ohYJ9hiwxb9rkCKcYwRWyEgtxktYIp3/qCyvaBuI0CM=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=htNj+K4kwmUoGpwSYlAwQb/3Ct8avNZ22nFLBOJLQ/wclRyUSsV6U87T1Ulj7OPFz\n\tNiHIBBmosy5f9aGF2HbrK+Hkwi9OIB969SMFizUzXLTebTkXWKK3dob+2boxhXbeAc\n\tGxOmt9DYLz8+xVQuEN5dlZrj2pVvarp5Fw2hFaps=","Date":"Wed, 20 Sep 2017 16:57:00 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170920065700.GO5520@umbus.fritz.box>","References":"<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"IpgPcFyQO6wM49Um\"","Content-Disposition":"inline","In-Reply-To":"<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771642,"web_url":"http://patchwork.ozlabs.org/comment/1771642/","msgid":"<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-20T07:18:55","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n>> >> David Gibson writes:\n>> >> \n>> >> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>> >> >> David Gibson writes:\n>> >> >> \n>> >> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> David Gibson writes:\n>> >> >> >> \n>> >> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> >> David Gibson writes:\n>> >> >> >> >> \n>> >> >> >> >> >> \n>> >> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> >> >> >> >> is equal to initial online vcpus / threads per core\n>> >> >> >> >> >> \n>> >> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> >> >> >> >> \n>> >> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> >> >> >> >> (max 2, at the moment)\n>> >> >> >> >> >> \n>> >> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >> >> >> >> >\n>> >> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n>> >> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n>> >> >> >> >> >\n>> >> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n>> >> >> >> >> >\n>> >> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> >> >> >> >> > it. That's just asking for confusion.\n>> >> >> >> >> \n>> >> >> >> >> This is the case where the user does not provide a topology(which is a\n>> >> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n>> >> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>> >> >> >> >\n>> >> >> >> > If you can find a way to override it by altering smp_cores when it's\n>> >> >> >> > not explicitly specified, then ok.\n>> >> >> >> \n>> >> >> >> Should I change the global smp_cores here as well ?\n>> >> >> >\n>> >> >> > I'm pretty uneasy with that option.\n>> >> >> \n>> >> >> Me too.\n>> >> >> \n>> >> >> > It would take a fair bit of checking to ensure that changing smp_cores\n>> >> >> > is safe here. An easier to verify option would be to make the generic\n>> >> >> > logic which splits up an unspecified -smp N into cores and sockets\n>> >> >> > more flexible, possibly based on machine options for max values.\n>> >> >> >\n>> >> >> > That might still be more trouble than its worth.\n>> >> >> \n>> >> >> I think the current approach is the simplest and less intrusive, as we\n>> >> >> are handling a case where user has not bothered to provide a detailed\n>> >> >> topology, the best we can do is create single threaded cores equal to\n>> >> >> number of cores.\n>> >> >\n>> >> > No, sorry. Having smp_cores not correspond to the number of cores per\n>> >> > chip in all cases is just not ok. Add an error message if the\n>> >> > topology isn't workable for powernv by all means. But users having to\n>> >> > use a longer command line is better than breaking basic assumptions\n>> >> > about what numbers reflect what topology.\n>> >> \n>> >> Sorry to ask again, as I am still not convinced, we do similar\n>> >> adjustment in spapr where the user did not provide the number of cores,\n>> >> but qemu assumes them as single threaded cores and created\n>> >> cores(boot_cores_nr) that were not same as smp_cores ?\n>> >\n>> > What? boot_cores_nr has absolutely nothing to do with adjusting the\n>> > topology, and it certainly doesn't assume they're single threaded.\n>> \n>> When we start a TCG guest and user provides following commandline, e.g.\n>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n>> with 4 cores, each having 1 thread.\n>\n> Ok.. and what's the problem with that behaviour on powernv?\n\nAs smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\ndefault value of 1 in vl.c. In powernv, we were setting nr-cores like\nthis:\n\n object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n\nEven when there were multiple cpus (-smp 4), when the guest boots up, we\njust get one core (i.e. smp_cores was 1) with single thread(smp_threads\nwas 1), which is wrong as per the command-line that was provided.\n\nRegards\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxrjV4Khxz9s81\n\tfor ;\n\tWed, 20 Sep 2017 17:19:58 +1000 (AEST)","from localhost ([::1]:47178 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duZIa-0005Fn-OT\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 03:19:56 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:35685)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duZHu-0004yf-24\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 03:19:15 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duZHq-0007yj-Nt\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 03:19:14 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:58638\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duZHq-0007xS-Id\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 03:19:10 -0400","from pps.filterd (m0098417.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8K7IvmB123541\n\tfor ; Wed, 20 Sep 2017 03:19:09 -0400","from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d3brrs9w9-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 03:19:09 -0400","from localhost\n\tby e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 20 Sep 2017 17:19:06 +1000","from d23relay10.au.ibm.com (202.81.31.229)\n\tby e23smtp08.au.ibm.com (202.81.31.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 20 Sep 2017 17:19:04 +1000","from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])\n\tby d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8K7J4F928770406; Wed, 20 Sep 2017 17:19:04 +1000","from d23av01.au.ibm.com (localhost [127.0.0.1])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8K7J46q009235; Wed, 20 Sep 2017 17:19:04 +1000","from abhimanyu.vnet.linux.ibm.com ([9.85.69.204])\n\tby d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8K7IuBq009071\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Wed, 20 Sep 2017 17:19:01 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170920065700.GO5520@umbus.fritz.box>","References":"<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>","Date":"Wed, 20 Sep 2017 12:48:55 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092007-0048-0000-0000-0000025D7571","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092007-0049-0000-0000-000048143731","Message-Id":"<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-20_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709200101","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771664,"web_url":"http://patchwork.ozlabs.org/comment/1771664/","msgid":"<90951ad0-ad4a-8649-f9f2-bb82dee276af@kaod.org>","list_archive_url":null,"date":"2017-09-20T08:12:59","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/20/2017 09:18 AM, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n>> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n>>> David Gibson writes:\n>>>\n>>>> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n>>>>> David Gibson writes:\n>>>>>\n>>>>>> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>>>>>>> David Gibson writes:\n>>>>>>>\n>>>>>>>> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>>>>>>>>> David Gibson writes:\n>>>>>>>>>\n>>>>>>>>>> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>>>>>>>>>>> David Gibson writes:\n>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> I thought, I am doing the same here for PowerNV, number of online cores\n>>>>>>>>>>>>> is equal to initial online vcpus / threads per core\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> int boot_cores_nr = smp_cpus / smp_threads;\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Only difference that I see in PowerNV is that we have multiple chips\n>>>>>>>>>>>>> (max 2, at the moment)\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>>>>>>>>>>>>\n>>>>>>>>>>>> This doesn't make sense to me. Cores per chip should *always* equal\n>>>>>>>>>>>> smp_cores, you shouldn't need another calculation for it.\n>>>>>>>>>>>>\n>>>>>>>>>>>>> And in case user has provided sane smp_cores, we use it.\n>>>>>>>>>>>>\n>>>>>>>>>>>> If smp_cores isn't sane, you should simply reject it, not try to fix\n>>>>>>>>>>>> it. That's just asking for confusion.\n>>>>>>>>>>>\n>>>>>>>>>>> This is the case where the user does not provide a topology(which is a\n>>>>>>>>>>> valid scenario), not sure we should reject it. So qemu defaults\n>>>>>>>>>>> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>>>>>>>>>>\n>>>>>>>>>> If you can find a way to override it by altering smp_cores when it's\n>>>>>>>>>> not explicitly specified, then ok.\n>>>>>>>>>\n>>>>>>>>> Should I change the global smp_cores here as well ?\n>>>>>>>>\n>>>>>>>> I'm pretty uneasy with that option.\n>>>>>>>\n>>>>>>> Me too.\n>>>>>>>\n>>>>>>>> It would take a fair bit of checking to ensure that changing smp_cores\n>>>>>>>> is safe here. An easier to verify option would be to make the generic\n>>>>>>>> logic which splits up an unspecified -smp N into cores and sockets\n>>>>>>>> more flexible, possibly based on machine options for max values.\n>>>>>>>>\n>>>>>>>> That might still be more trouble than its worth.\n>>>>>>>\n>>>>>>> I think the current approach is the simplest and less intrusive, as we\n>>>>>>> are handling a case where user has not bothered to provide a detailed\n>>>>>>> topology, the best we can do is create single threaded cores equal to\n>>>>>>> number of cores.\n>>>>>>\n>>>>>> No, sorry. Having smp_cores not correspond to the number of cores per\n>>>>>> chip in all cases is just not ok. Add an error message if the\n>>>>>> topology isn't workable for powernv by all means. But users having to\n>>>>>> use a longer command line is better than breaking basic assumptions\n>>>>>> about what numbers reflect what topology.\n>>>>>\n>>>>> Sorry to ask again, as I am still not convinced, we do similar\n>>>>> adjustment in spapr where the user did not provide the number of cores,\n>>>>> but qemu assumes them as single threaded cores and created\n>>>>> cores(boot_cores_nr) that were not same as smp_cores ?\n>>>>\n>>>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n>>>> topology, and it certainly doesn't assume they're single threaded.\n>>>\n>>> When we start a TCG guest and user provides following commandline, e.g.\n>>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n>>> with 4 cores, each having 1 thread.\n>>\n>> Ok.. and what's the problem with that behaviour on powernv?\n> \n> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> this:\n> \n> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> \n> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> was 1), which is wrong as per the command-line that was provided.\n\nI have never noticed as always use the cores= option but if you use\nthe following on a powernv machine:\n\n -smp 4\t\t\t\t1 cpu\n -smp cpus=4,threads=1\t\t1 cpu\n -smp cores=4,threads=1\t\t4 cpus\n -smp cpus=4,cores=4,threads=1\t4 cpus\n -smp cpus=1,cores=4,threads=1\tfails\n -smp cpus=4,cores=1,threads=1\t1 cpu\n\nShould we be using 'smp_cpus' instead of 'smp_cores' then ? Honestly,\nI feel a bit lost with all default behaviors.\n\nC.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxsvX6xL6z9s8J\n\tfor ;\n\tWed, 20 Sep 2017 18:13:44 +1000 (AEST)","from localhost ([::1]:47346 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dua8d-0002vn-4V\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 04:13:43 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:58857)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dua8C-0002u0-AN\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 04:13:17 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dua86-0005tJ-5S\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 04:13:16 -0400","from 5.mo2.mail-out.ovh.net ([87.98.181.248]:37948)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dua85-0005ms-ST\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 04:13:10 -0400","from player157.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo2.mail-out.ovh.net (Postfix) with ESMTP id 51BD8AC9D5\n\tfor ; Wed, 20 Sep 2017 10:13:08 +0200 (CEST)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player157.ha.ovh.net (Postfix) with ESMTPSA id 3188650007E;\n\tWed, 20 Sep 2017 10:13:00 +0200 (CEST)"],"To":"Nikunj A Dadhania ,\n\tDavid Gibson ","References":"<20170915064830.GI5250@umbus.fritz.box>\n\t<87377omkuk.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"<90951ad0-ad4a-8649-f9f2-bb82dee276af@kaod.org>","Date":"Wed, 20 Sep 2017 10:12:59 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Ovh-Tracer-Id":"2527645291572530033","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrheelgddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"87.98.181.248","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771833,"web_url":"http://patchwork.ozlabs.org/comment/1771833/","msgid":"<20170920115342.GQ5520@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-20T11:53:42","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n> >> >> David Gibson writes:\n> >> >> \n> >> >> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> >> >> >> David Gibson writes:\n> >> >> >> \n> >> >> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> David Gibson writes:\n> >> >> >> >> \n> >> >> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> >> David Gibson writes:\n> >> >> >> >> >> \n> >> >> >> >> >> >> \n> >> >> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> >> >> >> >> is equal to initial online vcpus / threads per core\n> >> >> >> >> >> >> \n> >> >> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> >> >> >> >> \n> >> >> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> >> >> >> >> (max 2, at the moment)\n> >> >> >> >> >> >> \n> >> >> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >> >> >> >> >\n> >> >> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> >> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >> >> >> >> >\n> >> >> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >> >> >> >> >\n> >> >> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> >> >> >> >> > it. That's just asking for confusion.\n> >> >> >> >> >> \n> >> >> >> >> >> This is the case where the user does not provide a topology(which is a\n> >> >> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> >> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >> >> >> >> >\n> >> >> >> >> > If you can find a way to override it by altering smp_cores when it's\n> >> >> >> >> > not explicitly specified, then ok.\n> >> >> >> >> \n> >> >> >> >> Should I change the global smp_cores here as well ?\n> >> >> >> >\n> >> >> >> > I'm pretty uneasy with that option.\n> >> >> >> \n> >> >> >> Me too.\n> >> >> >> \n> >> >> >> > It would take a fair bit of checking to ensure that changing smp_cores\n> >> >> >> > is safe here. An easier to verify option would be to make the generic\n> >> >> >> > logic which splits up an unspecified -smp N into cores and sockets\n> >> >> >> > more flexible, possibly based on machine options for max values.\n> >> >> >> >\n> >> >> >> > That might still be more trouble than its worth.\n> >> >> >> \n> >> >> >> I think the current approach is the simplest and less intrusive, as we\n> >> >> >> are handling a case where user has not bothered to provide a detailed\n> >> >> >> topology, the best we can do is create single threaded cores equal to\n> >> >> >> number of cores.\n> >> >> >\n> >> >> > No, sorry. Having smp_cores not correspond to the number of cores per\n> >> >> > chip in all cases is just not ok. Add an error message if the\n> >> >> > topology isn't workable for powernv by all means. But users having to\n> >> >> > use a longer command line is better than breaking basic assumptions\n> >> >> > about what numbers reflect what topology.\n> >> >> \n> >> >> Sorry to ask again, as I am still not convinced, we do similar\n> >> >> adjustment in spapr where the user did not provide the number of cores,\n> >> >> but qemu assumes them as single threaded cores and created\n> >> >> cores(boot_cores_nr) that were not same as smp_cores ?\n> >> >\n> >> > What? boot_cores_nr has absolutely nothing to do with adjusting the\n> >> > topology, and it certainly doesn't assume they're single threaded.\n> >> \n> >> When we start a TCG guest and user provides following commandline, e.g.\n> >> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> >> with 4 cores, each having 1 thread.\n> >\n> > Ok.. and what's the problem with that behaviour on powernv?\n> \n> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> this:\n> \n> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> \n> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> was 1), which is wrong as per the command-line that was provided.\n\nRight, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\nthread. If you can't supply 4 sockets you should error, but you\nshouldn't go and change the number of cores per socket.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"dJVq0F4A\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy0ZB6QBrz9s06\n\tfor ;\n\tWed, 20 Sep 2017 23:14:10 +1000 (AEST)","from localhost ([::1]:47997 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duepM-0000aJ-Ue\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 09:14:09 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:41617)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duenI-0007jr-ME\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:12:33 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duemf-0006tt-Rl\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 09:12:00 -0400","from ozlabs.org ([103.22.144.67]:46581)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duemf-0006p2-G0; Wed, 20 Sep 2017 09:11:21 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xxyp963vYz9sRm; Wed, 20 Sep 2017 21:54:25 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505908465;\n\tbh=gb5/egsubVn3vH3KDi8kR9fPfInrlUJNGjKAjqdjXl0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=dJVq0F4A2a5JFHTkA393ptSHC5Ox6LrkITYZUXvzV1IIcmvcNQvIKXfNQuTOPQXx/\n\tJ24AmSHB9Fu0w+RJGpgqx24+bpyBvpnaCszgnSNbf9UDj0Mqo0s1mb/ucAkovda1rI\n\t9Wqv8Rl8lugFMvuqGIhhJihvKb0rOdxgFHy6xhpM=","Date":"Wed, 20 Sep 2017 21:53:42 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170920115342.GQ5520@umbus.fritz.box>","References":"<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"i/CQJCAqWP/GQJtX\"","Content-Disposition":"inline","In-Reply-To":"<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"103.22.144.67","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1772397,"web_url":"http://patchwork.ozlabs.org/comment/1772397/","msgid":"<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-21T03:54:46","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n> On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote:\n>> David Gibson writes:\n>> \n>> > On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n>> >> David Gibson writes:\n>> >> \n>> >> > On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n>> >> >> David Gibson writes:\n>> >> >> \n>> >> >> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> David Gibson writes:\n>> >> >> >> \n>> >> >> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> >> David Gibson writes:\n>> >> >> >> >> \n>> >> >> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>> >> >> >> >> >> David Gibson writes:\n>> >> >> >> >> >> \n>> >> >> >> >> >> >> \n>> >> >> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n>> >> >> >> >> >> >> is equal to initial online vcpus / threads per core\n>> >> >> >> >> >> >> \n>> >> >> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n>> >> >> >> >> >> >> \n>> >> >> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n>> >> >> >> >> >> >> (max 2, at the moment)\n>> >> >> >> >> >> >> \n>> >> >> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>> >> >> >> >> >> >\n>> >> >> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n>> >> >> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n>> >> >> >> >> >> >\n>> >> >> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n>> >> >> >> >> >> >\n>> >> >> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n>> >> >> >> >> >> > it. That's just asking for confusion.\n>> >> >> >> >> >> \n>> >> >> >> >> >> This is the case where the user does not provide a topology(which is a\n>> >> >> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n>> >> >> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>> >> >> >> >> >\n>> >> >> >> >> > If you can find a way to override it by altering smp_cores when it's\n>> >> >> >> >> > not explicitly specified, then ok.\n>> >> >> >> >> \n>> >> >> >> >> Should I change the global smp_cores here as well ?\n>> >> >> >> >\n>> >> >> >> > I'm pretty uneasy with that option.\n>> >> >> >> \n>> >> >> >> Me too.\n>> >> >> >> \n>> >> >> >> > It would take a fair bit of checking to ensure that changing smp_cores\n>> >> >> >> > is safe here. An easier to verify option would be to make the generic\n>> >> >> >> > logic which splits up an unspecified -smp N into cores and sockets\n>> >> >> >> > more flexible, possibly based on machine options for max values.\n>> >> >> >> >\n>> >> >> >> > That might still be more trouble than its worth.\n>> >> >> >> \n>> >> >> >> I think the current approach is the simplest and less intrusive, as we\n>> >> >> >> are handling a case where user has not bothered to provide a detailed\n>> >> >> >> topology, the best we can do is create single threaded cores equal to\n>> >> >> >> number of cores.\n>> >> >> >\n>> >> >> > No, sorry. Having smp_cores not correspond to the number of cores per\n>> >> >> > chip in all cases is just not ok. Add an error message if the\n>> >> >> > topology isn't workable for powernv by all means. But users having to\n>> >> >> > use a longer command line is better than breaking basic assumptions\n>> >> >> > about what numbers reflect what topology.\n>> >> >> \n>> >> >> Sorry to ask again, as I am still not convinced, we do similar\n>> >> >> adjustment in spapr where the user did not provide the number of cores,\n>> >> >> but qemu assumes them as single threaded cores and created\n>> >> >> cores(boot_cores_nr) that were not same as smp_cores ?\n>> >> >\n>> >> > What? boot_cores_nr has absolutely nothing to do with adjusting the\n>> >> > topology, and it certainly doesn't assume they're single threaded.\n>> >> \n>> >> When we start a TCG guest and user provides following commandline, e.g.\n>> >> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n>> >> with 4 cores, each having 1 thread.\n>> >\n>> > Ok.. and what's the problem with that behaviour on powernv?\n>> \n>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n>> this:\n>> \n>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n>> \n>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n>> was 1), which is wrong as per the command-line that was provided.\n>\n> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> thread. If you can't supply 4 sockets you should error, but you\n> shouldn't go and change the number of cores per socket.\n\nOK, that makes sense now. And I do see that smp_cpus is 4 in the above\ncase. Now looking more into it, i see that powernv has something called\n\"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n\nRegards,\nNikunj","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyN8j3wWnz9s7c\n\tfor ;\n\tThu, 21 Sep 2017 13:56:53 +1000 (AEST)","from localhost ([::1]:51649 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dusbb-0001Bo-92\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 23:56:51 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:43661)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dusb8-0001BX-19\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 23:56:23 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dusb3-0003V3-5k\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 23:56:22 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40308)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dusb2-0003UO-Ts\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 23:56:17 -0400","from pps.filterd (m0098409.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8L3slXx042198\n\tfor ; Wed, 20 Sep 2017 23:56:15 -0400","from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d44uvkghw-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 20 Sep 2017 23:56:15 -0400","from localhost\n\tby e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 21 Sep 2017 13:56:12 +1000","from d23relay08.au.ibm.com (202.81.31.227)\n\tby e23smtp06.au.ibm.com (202.81.31.212) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 21 Sep 2017 13:56:10 +1000","from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119])\n\tby d23relay08.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8L3st8g39452712; Thu, 21 Sep 2017 13:54:55 +1000","from d23av05.au.ibm.com (localhost [127.0.0.1])\n\tby d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8L3sslP004318; Thu, 21 Sep 2017 13:54:55 +1000","from abhimanyu.vnet.linux.ibm.com (abhimanyu.in.ibm.com\n\t[9.124.35.198])\n\tby d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8L3sld3004240\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Thu, 21 Sep 2017 13:54:52 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170920115342.GQ5520@umbus.fritz.box>","References":"<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>","Date":"Thu, 21 Sep 2017 09:24:46 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092103-0040-0000-0000-0000035712EA","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092103-0041-0000-0000-00000CD7D0D8","Message-Id":"<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-21_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709210052","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.156.1","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1772431,"web_url":"http://patchwork.ozlabs.org/comment/1772431/","msgid":"","list_archive_url":null,"date":"2017-09-21T06:04:55","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/21/2017 05:54 AM, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n>> On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote:\n>>> David Gibson writes:\n>>>\n>>>> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n>>>>> David Gibson writes:\n>>>>>\n>>>>>> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n>>>>>>> David Gibson writes:\n>>>>>>>\n>>>>>>>> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n>>>>>>>>> David Gibson writes:\n>>>>>>>>>\n>>>>>>>>>> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n>>>>>>>>>>> David Gibson writes:\n>>>>>>>>>>>\n>>>>>>>>>>>> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n>>>>>>>>>>>>> David Gibson writes:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> I thought, I am doing the same here for PowerNV, number of online cores\n>>>>>>>>>>>>>>> is equal to initial online vcpus / threads per core\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> int boot_cores_nr = smp_cpus / smp_threads;\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Only difference that I see in PowerNV is that we have multiple chips\n>>>>>>>>>>>>>>> (max 2, at the moment)\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>> This doesn't make sense to me. Cores per chip should *always* equal\n>>>>>>>>>>>>>> smp_cores, you shouldn't need another calculation for it.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> And in case user has provided sane smp_cores, we use it.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>> If smp_cores isn't sane, you should simply reject it, not try to fix\n>>>>>>>>>>>>>> it. That's just asking for confusion.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> This is the case where the user does not provide a topology(which is a\n>>>>>>>>>>>>> valid scenario), not sure we should reject it. So qemu defaults\n>>>>>>>>>>>>> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n>>>>>>>>>>>>\n>>>>>>>>>>>> If you can find a way to override it by altering smp_cores when it's\n>>>>>>>>>>>> not explicitly specified, then ok.\n>>>>>>>>>>>\n>>>>>>>>>>> Should I change the global smp_cores here as well ?\n>>>>>>>>>>\n>>>>>>>>>> I'm pretty uneasy with that option.\n>>>>>>>>>\n>>>>>>>>> Me too.\n>>>>>>>>>\n>>>>>>>>>> It would take a fair bit of checking to ensure that changing smp_cores\n>>>>>>>>>> is safe here. An easier to verify option would be to make the generic\n>>>>>>>>>> logic which splits up an unspecified -smp N into cores and sockets\n>>>>>>>>>> more flexible, possibly based on machine options for max values.\n>>>>>>>>>>\n>>>>>>>>>> That might still be more trouble than its worth.\n>>>>>>>>>\n>>>>>>>>> I think the current approach is the simplest and less intrusive, as we\n>>>>>>>>> are handling a case where user has not bothered to provide a detailed\n>>>>>>>>> topology, the best we can do is create single threaded cores equal to\n>>>>>>>>> number of cores.\n>>>>>>>>\n>>>>>>>> No, sorry. Having smp_cores not correspond to the number of cores per\n>>>>>>>> chip in all cases is just not ok. Add an error message if the\n>>>>>>>> topology isn't workable for powernv by all means. But users having to\n>>>>>>>> use a longer command line is better than breaking basic assumptions\n>>>>>>>> about what numbers reflect what topology.\n>>>>>>>\n>>>>>>> Sorry to ask again, as I am still not convinced, we do similar\n>>>>>>> adjustment in spapr where the user did not provide the number of cores,\n>>>>>>> but qemu assumes them as single threaded cores and created\n>>>>>>> cores(boot_cores_nr) that were not same as smp_cores ?\n>>>>>>\n>>>>>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n>>>>>> topology, and it certainly doesn't assume they're single threaded.\n>>>>>\n>>>>> When we start a TCG guest and user provides following commandline, e.g.\n>>>>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n>>>>> with 4 cores, each having 1 thread.\n>>>>\n>>>> Ok.. and what's the problem with that behaviour on powernv?\n>>>\n>>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n>>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n>>> this:\n>>>\n>>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n>>>\n>>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n>>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n>>> was 1), which is wrong as per the command-line that was provided.\n>>\n>> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n>> thread. If you can't supply 4 sockets you should error, but you\n>> shouldn't go and change the number of cores per socket.\n> \n> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> case. Now looking more into it, i see that powernv has something called\n> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n\nyes that would do for cpus, but how do we retrieve the number of \nsockets ? I don't see a smp_sockets. \n\nIf we start looking at such issues, we should also take into account \nmemory distribution :\n\n -numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n\nwould allow us to define a set of cpus per node, cpus should be evenly \ndistributed on the nodes though, and also define memory per node, but \nsome nodes could be without memory. \n\nC.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyR1J6DPjz9sNw\n\tfor ;\n\tThu, 21 Sep 2017 16:05:40 +1000 (AEST)","from localhost ([::1]:51947 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duucE-00040g-WF\n\tfor incoming@patchwork.ozlabs.org; Thu, 21 Sep 2017 02:05:39 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:60540)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duubo-0003yE-2k\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 02:05:13 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duubj-0002dT-3W\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 02:05:12 -0400","from 5.mo2.mail-out.ovh.net ([87.98.181.248]:47986)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1duubi-0002cW-QI\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 02:05:07 -0400","from player157.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo2.mail-out.ovh.net (Postfix) with ESMTP id 33790AC995\n\tfor ; Thu, 21 Sep 2017 08:05:03 +0200 (CEST)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player157.ha.ovh.net (Postfix) with ESMTPSA id C328E50008D;\n\tThu, 21 Sep 2017 08:04:55 +0200 (CEST)"],"To":"Nikunj A Dadhania ,\n\tDavid Gibson ","References":"<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Thu, 21 Sep 2017 08:04:55 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Ovh-Tracer-Id":"6236922538212887409","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledriedugddutdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"87.98.181.248","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1772446,"web_url":"http://patchwork.ozlabs.org/comment/1772446/","msgid":"<20170921053107.GD4998@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-21T05:31:07","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Thu, Sep 21, 2017 at 09:24:46AM +0530, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n> > On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote:\n> >> David Gibson writes:\n> >> \n> >> > On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n> >> >> David Gibson writes:\n> >> >> \n> >> >> > On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n> >> >> >> David Gibson writes:\n> >> >> >> \n> >> >> >> > On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> David Gibson writes:\n> >> >> >> >> \n> >> >> >> >> > On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> >> David Gibson writes:\n> >> >> >> >> >> \n> >> >> >> >> >> > On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >> >> >> >> >> >> David Gibson writes:\n> >> >> >> >> >> >> \n> >> >> >> >> >> >> >> \n> >> >> >> >> >> >> >> I thought, I am doing the same here for PowerNV, number of online cores\n> >> >> >> >> >> >> >> is equal to initial online vcpus / threads per core\n> >> >> >> >> >> >> >> \n> >> >> >> >> >> >> >> int boot_cores_nr = smp_cpus / smp_threads;\n> >> >> >> >> >> >> >> \n> >> >> >> >> >> >> >> Only difference that I see in PowerNV is that we have multiple chips\n> >> >> >> >> >> >> >> (max 2, at the moment)\n> >> >> >> >> >> >> >> \n> >> >> >> >> >> >> >> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >> >> >> >> >> >> >\n> >> >> >> >> >> >> > This doesn't make sense to me. Cores per chip should *always* equal\n> >> >> >> >> >> >> > smp_cores, you shouldn't need another calculation for it.\n> >> >> >> >> >> >> >\n> >> >> >> >> >> >> >> And in case user has provided sane smp_cores, we use it.\n> >> >> >> >> >> >> >\n> >> >> >> >> >> >> > If smp_cores isn't sane, you should simply reject it, not try to fix\n> >> >> >> >> >> >> > it. That's just asking for confusion.\n> >> >> >> >> >> >> \n> >> >> >> >> >> >> This is the case where the user does not provide a topology(which is a\n> >> >> >> >> >> >> valid scenario), not sure we should reject it. So qemu defaults\n> >> >> >> >> >> >> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >> >> >> >> >> >\n> >> >> >> >> >> > If you can find a way to override it by altering smp_cores when it's\n> >> >> >> >> >> > not explicitly specified, then ok.\n> >> >> >> >> >> \n> >> >> >> >> >> Should I change the global smp_cores here as well ?\n> >> >> >> >> >\n> >> >> >> >> > I'm pretty uneasy with that option.\n> >> >> >> >> \n> >> >> >> >> Me too.\n> >> >> >> >> \n> >> >> >> >> > It would take a fair bit of checking to ensure that changing smp_cores\n> >> >> >> >> > is safe here. An easier to verify option would be to make the generic\n> >> >> >> >> > logic which splits up an unspecified -smp N into cores and sockets\n> >> >> >> >> > more flexible, possibly based on machine options for max values.\n> >> >> >> >> >\n> >> >> >> >> > That might still be more trouble than its worth.\n> >> >> >> >> \n> >> >> >> >> I think the current approach is the simplest and less intrusive, as we\n> >> >> >> >> are handling a case where user has not bothered to provide a detailed\n> >> >> >> >> topology, the best we can do is create single threaded cores equal to\n> >> >> >> >> number of cores.\n> >> >> >> >\n> >> >> >> > No, sorry. Having smp_cores not correspond to the number of cores per\n> >> >> >> > chip in all cases is just not ok. Add an error message if the\n> >> >> >> > topology isn't workable for powernv by all means. But users having to\n> >> >> >> > use a longer command line is better than breaking basic assumptions\n> >> >> >> > about what numbers reflect what topology.\n> >> >> >> \n> >> >> >> Sorry to ask again, as I am still not convinced, we do similar\n> >> >> >> adjustment in spapr where the user did not provide the number of cores,\n> >> >> >> but qemu assumes them as single threaded cores and created\n> >> >> >> cores(boot_cores_nr) that were not same as smp_cores ?\n> >> >> >\n> >> >> > What? boot_cores_nr has absolutely nothing to do with adjusting the\n> >> >> > topology, and it certainly doesn't assume they're single threaded.\n> >> >> \n> >> >> When we start a TCG guest and user provides following commandline, e.g.\n> >> >> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> >> >> with 4 cores, each having 1 thread.\n> >> >\n> >> > Ok.. and what's the problem with that behaviour on powernv?\n> >> \n> >> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> >> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> >> this:\n> >> \n> >> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> >> \n> >> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> >> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> >> was 1), which is wrong as per the command-line that was provided.\n> >\n> > Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> > thread. If you can't supply 4 sockets you should error, but you\n> > shouldn't go and change the number of cores per socket.\n> \n> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> case. Now looking more into it, i see that powernv has something called\n> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n\nAh, yes, I see. It's probably still reasonable to keep num_chips as\nan internal variable, rather than using (smp_cpus / smp_cores /\nsmp_threads) everywhere. But we shouldn't have it as a direct\nuser-settable property, instead setting it from the -smp command line\noption.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"PD45qimf\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyRZ7181Fz9t3m\n\tfor ;\n\tThu, 21 Sep 2017 16:30:39 +1000 (AEST)","from localhost ([::1]:52038 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duv0P-0004XK-8X\n\tfor incoming@patchwork.ozlabs.org; Thu, 21 Sep 2017 02:30:37 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:38606)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duuzJ-000473-Tg\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 02:29:31 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duuzI-00063h-Cq\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 02:29:29 -0400","from ozlabs.org ([2401:3900:2:1::2]:43239)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duuzH-00063D-Of; Thu, 21 Sep 2017 02:29:28 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xyRXh66lDz9t3v; Thu, 21 Sep 2017 16:29:24 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1505975364;\n\tbh=CSVHhWs02X/z8eSDxdQphsBOfdH6DkbiKr93vpORKp0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=PD45qimf+g4DnmVnWq2pivRWDktkwGVFBhuTFXMJAPoYMuV0Gb8shjcpF1BOxsl0p\n\tZoYieX/SyIG5wRVBNTAUiCODRXfaSDy9fOC/pd+hOmLyLN25UULTWRans7ni1dbi0h\n\tbiSenPXZkd2ArjHrogACCzMT6IhN/0TEyPg7Qz/M=","Date":"Thu, 21 Sep 2017 15:31:07 +1000","From":"David Gibson ","To":"Nikunj A Dadhania ","Message-ID":"<20170921053107.GD4998@umbus.fritz.box>","References":"<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"9UV9rz0O2dU/yYYn\"","Content-Disposition":"inline","In-Reply-To":"<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1772501,"web_url":"http://patchwork.ozlabs.org/comment/1772501/","msgid":"<20170921094226.0e4c4ac6@nial.brq.redhat.com>","list_archive_url":null,"date":"2017-09-21T07:42:26","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":11305,"url":"http://patchwork.ozlabs.org/api/people/11305/","name":"Igor Mammedov","email":"imammedo@redhat.com"},"content":"On Thu, 21 Sep 2017 08:04:55 +0200\nCédric Le Goater wrote:\n\n> On 09/21/2017 05:54 AM, Nikunj A Dadhania wrote:\n> > David Gibson writes:\n> > \n> >> On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote: \n> >>> David Gibson writes:\n> >>> \n> >>>> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote: \n> >>>>> David Gibson writes:\n> >>>>> \n> >>>>>> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote: \n> >>>>>>> David Gibson writes:\n> >>>>>>> \n> >>>>>>>> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote: \n> >>>>>>>>> David Gibson writes:\n> >>>>>>>>> \n> >>>>>>>>>> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote: \n> >>>>>>>>>>> David Gibson writes:\n> >>>>>>>>>>> \n> >>>>>>>>>>>> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote: \n> >>>>>>>>>>>>> David Gibson writes:\n> >>>>>>>>>>>>> \n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> I thought, I am doing the same here for PowerNV, number of online cores\n> >>>>>>>>>>>>>>> is equal to initial online vcpus / threads per core\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> int boot_cores_nr = smp_cpus / smp_threads;\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> Only difference that I see in PowerNV is that we have multiple chips\n> >>>>>>>>>>>>>>> (max 2, at the moment)\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips); \n> >>>>>>>>>>>>>>\n> >>>>>>>>>>>>>> This doesn't make sense to me. Cores per chip should *always* equal\n> >>>>>>>>>>>>>> smp_cores, you shouldn't need another calculation for it.\n> >>>>>>>>>>>>>> \n> >>>>>>>>>>>>>>> And in case user has provided sane smp_cores, we use it. \n> >>>>>>>>>>>>>>\n> >>>>>>>>>>>>>> If smp_cores isn't sane, you should simply reject it, not try to fix\n> >>>>>>>>>>>>>> it. That's just asking for confusion. \n> >>>>>>>>>>>>>\n> >>>>>>>>>>>>> This is the case where the user does not provide a topology(which is a\n> >>>>>>>>>>>>> valid scenario), not sure we should reject it. So qemu defaults\n> >>>>>>>>>>>>> smp_cores/smt_threads to 1. I think it makes sense to over-ride. \n> >>>>>>>>>>>>\n> >>>>>>>>>>>> If you can find a way to override it by altering smp_cores when it's\n> >>>>>>>>>>>> not explicitly specified, then ok. \n> >>>>>>>>>>>\n> >>>>>>>>>>> Should I change the global smp_cores here as well ? \n> >>>>>>>>>>\n> >>>>>>>>>> I'm pretty uneasy with that option. \n> >>>>>>>>>\n> >>>>>>>>> Me too.\n> >>>>>>>>> \n> >>>>>>>>>> It would take a fair bit of checking to ensure that changing smp_cores\n> >>>>>>>>>> is safe here. An easier to verify option would be to make the generic\n> >>>>>>>>>> logic which splits up an unspecified -smp N into cores and sockets\n> >>>>>>>>>> more flexible, possibly based on machine options for max values.\n> >>>>>>>>>>\n> >>>>>>>>>> That might still be more trouble than its worth. \n> >>>>>>>>>\n> >>>>>>>>> I think the current approach is the simplest and less intrusive, as we\n> >>>>>>>>> are handling a case where user has not bothered to provide a detailed\n> >>>>>>>>> topology, the best we can do is create single threaded cores equal to\n> >>>>>>>>> number of cores. \n> >>>>>>>>\n> >>>>>>>> No, sorry. Having smp_cores not correspond to the number of cores per\n> >>>>>>>> chip in all cases is just not ok. Add an error message if the\n> >>>>>>>> topology isn't workable for powernv by all means. But users having to\n> >>>>>>>> use a longer command line is better than breaking basic assumptions\n> >>>>>>>> about what numbers reflect what topology. \n> >>>>>>>\n> >>>>>>> Sorry to ask again, as I am still not convinced, we do similar\n> >>>>>>> adjustment in spapr where the user did not provide the number of cores,\n> >>>>>>> but qemu assumes them as single threaded cores and created\n> >>>>>>> cores(boot_cores_nr) that were not same as smp_cores ? \n> >>>>>>\n> >>>>>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n> >>>>>> topology, and it certainly doesn't assume they're single threaded. \n> >>>>>\n> >>>>> When we start a TCG guest and user provides following commandline, e.g.\n> >>>>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> >>>>> with 4 cores, each having 1 thread. \n> >>>>\n> >>>> Ok.. and what's the problem with that behaviour on powernv? \n> >>>\n> >>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> >>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> >>> this:\n> >>>\n> >>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> >>>\n> >>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> >>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> >>> was 1), which is wrong as per the command-line that was provided. \n> >>\n> >> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> >> thread. If you can't supply 4 sockets you should error, but you\n> >> shouldn't go and change the number of cores per socket. \n> > \n> > OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> > case. Now looking more into it, i see that powernv has something called\n> > \"num_chips\", isnt this same as sockets ? Do we need num_chips separately? \n> \n> yes that would do for cpus, but how do we retrieve the number of \n> sockets ? I don't see a smp_sockets. \nI'd suggest to rewrite QEMU again :)\n\nmore exactly, -smp parsing is global and sometimes doesn't suite\ntarget device model/machine.\nIdea was to make it's options machine properties to get rid of globals\nand then let leaf machine redefine parsing behaviour.\nhere is Drew's take on it:\n\n[Qemu-devel] [PATCH RFC 00/16] Rework SMP parameters\nhttps://www.mail-archive.com/qemu-devel@nongnu.org/msg376961.html\n\nconsidering there weren't pressing need, the series has been pushed\nto the end of TODO list. Maybe you can revive it and make work for\npnv and other machines.\n\n\n> If we start looking at such issues, we should also take into account \n> memory distribution :\n> \n> -numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node]\nit's interface based on cpu_index, which internal qemu number for\nan 1 cpu execution context.\n\nIt would be better if one would use new interface with new machines\n -numa cpu,node-id=0,socket-id=0 ...\n\n> \n> would allow us to define a set of cpus per node, cpus should be evenly \n> distributed on the nodes though, and also define memory per node, but \n> some nodes could be without memory. \n> \n> C. \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=imammedo@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyT9r45jGz9sNc\n\tfor ;\n\tThu, 21 Sep 2017 17:43:12 +1000 (AEST)","from localhost ([::1]:52193 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duw8c-0004Uz-ME\n\tfor incoming@patchwork.ozlabs.org; Thu, 21 Sep 2017 03:43:10 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:60462)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duw82-0004TA-Vt\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 03:42:36 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duw7z-00049r-SV\n\tfor qemu-devel@nongnu.org; Thu, 21 Sep 2017 03:42:35 -0400","from mx1.redhat.com ([209.132.183.28]:53926)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duw7z-00049f-Jb; Thu, 21 Sep 2017 03:42:31 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 32540CD183;\n\tThu, 21 Sep 2017 07:42:30 +0000 (UTC)","from nial.brq.redhat.com (unknown [10.43.2.209])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id A27C760D10;\n\tThu, 21 Sep 2017 07:42:28 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 32540CD183","Date":"Thu, 21 Sep 2017 09:42:26 +0200","From":"Igor Mammedov ","To":"=?utf-8?q?C=C3=A9dric?= Le Goater ","Message-ID":"<20170921094226.0e4c4ac6@nial.brq.redhat.com>","In-Reply-To":"","References":"<20170915085115.GN5250@umbus.fritz.box>\n\t<87y3pgl45f.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"quoted-printable","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tThu, 21 Sep 2017 07:42:30 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tNikunj A Dadhania ,\n\tDavid Gibson ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773284,"web_url":"http://patchwork.ozlabs.org/comment/1773284/","msgid":"<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-22T06:00:51","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":17189,"url":"http://patchwork.ozlabs.org/api/people/17189/","name":"Nikunj A Dadhania","email":"nikunj@linux.vnet.ibm.com"},"content":"David Gibson writes:\n\n>> >> \n>> >> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n>> >> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n>> >> this:\n>> >> \n>> >> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n>> >> \n>> >> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n>> >> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n>> >> was 1), which is wrong as per the command-line that was provided.\n>> >\n>> > Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n>> > thread. If you can't supply 4 sockets you should error, but you\n>> > shouldn't go and change the number of cores per socket.\n>> \n>> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n>> case. Now looking more into it, i see that powernv has something called\n>> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n>\n> Ah, yes, I see. It's probably still reasonable to keep num_chips as\n> an internal variable, rather than using (smp_cpus / smp_cores /\n> smp_threads) everywhere. But we shouldn't have it as a direct\n> user-settable property, instead setting it from the -smp command line\n> option.\n\nSomething like the below works till num_chips=2, after that guest does\nnot boot up. This might be some limitation within the OS, Cedric might\nhave some clue. Otherwise, I see that multiple chips are created with\nsingle core having single thread.\n\n ppc/pnv: Use num_chips for multiple sockets\n \n When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n initialize 4 cpus. QEMU assumes smp_threads and smp_cores both as 1. Make sure\n that we initialize multiple chips for this.\n \n Remove the user-settable property num_chips from machine command line option\n \n Signed-off-by: Nikunj A Dadhania \n\ndiff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c\nindex 9724719..fa501f9 100644\n--- a/hw/ppc/pnv.c\n+++ b/hw/ppc/pnv.c\n@@ -709,7 +709,17 @@ static void ppc_powernv_init(MachineState *machine)\n exit(1);\n }\n \n+ pnv->num_chips = smp_cpus / (smp_cores * smp_threads);\n pnv->chips = g_new0(PnvChip *, pnv->num_chips);\n+\n+ if (smp_cpus != (smp_threads * pnv->num_chips * smp_cores)) {\n+ error_report(\"cpu topology not balanced: \"\n+ \"chips (%u) * cores (%u) * threads (%u) != \"\n+ \"number of cpus (%u)\",\n+ pnv->num_chips, smp_cores, smp_threads, smp_cpus);\n+ exit(1);\n+ }\n+\n for (i = 0; i < pnv->num_chips; i++) {\n char chip_name[32];\n Object *chip = object_new(chip_typename);\n@@ -1255,53 +1265,12 @@ static void pnv_pic_print_info(InterruptStatsProvider *obj,\n }\n }\n \n-static void pnv_get_num_chips(Object *obj, Visitor *v, const char *name,\n- void *opaque, Error **errp)\n-{\n- visit_type_uint32(v, name, &POWERNV_MACHINE(obj)->num_chips, errp);\n-}\n-\n-static void pnv_set_num_chips(Object *obj, Visitor *v, const char *name,\n- void *opaque, Error **errp)\n-{\n- PnvMachineState *pnv = POWERNV_MACHINE(obj);\n- uint32_t num_chips;\n- Error *local_err = NULL;\n-\n- visit_type_uint32(v, name, &num_chips, &local_err);\n- if (local_err) {\n- error_propagate(errp, local_err);\n- return;\n- }\n-\n- /*\n- * TODO: should we decide on how many chips we can create based\n- * on #cores and Venice vs. Murano vs. Naples chip type etc...,\n- */\n- if (!is_power_of_2(num_chips) || num_chips > 4) {\n- error_setg(errp, \"invalid number of chips: '%d'\", num_chips);\n- return;\n- }\n-\n- pnv->num_chips = num_chips;\n-}\n-\n static void powernv_machine_initfn(Object *obj)\n {\n PnvMachineState *pnv = POWERNV_MACHINE(obj);\n pnv->num_chips = 1;\n }\n \n-static void powernv_machine_class_props_init(ObjectClass *oc)\n-{\n- object_class_property_add(oc, \"num-chips\", \"uint32\",\n- pnv_get_num_chips, pnv_set_num_chips,\n- NULL, NULL, NULL);\n- object_class_property_set_description(oc, \"num-chips\",\n- \"Specifies the number of processor chips\",\n- NULL);\n-}\n-\n static void powernv_machine_class_init(ObjectClass *oc, void *data)\n {\n MachineClass *mc = MACHINE_CLASS(oc);\n@@ -1321,8 +1290,6 @@ static void powernv_machine_class_init(ObjectClass *oc, void *data)\n xic->ics_get = pnv_ics_get;\n xic->ics_resend = pnv_ics_resend;\n ispc->print_info = pnv_pic_print_info;\n-\n- powernv_machine_class_props_init(oc);\n }\n \n static const TypeInfo powernv_machine_info = {","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz2tw4GCLz9sBd\n\tfor ;\n\tFri, 22 Sep 2017 16:02:16 +1000 (AEST)","from localhost ([::1]:56795 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvH2U-0002pg-Pt\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 02:02:14 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:46770)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvH1i-0002Vc-F7\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:01:27 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvH1f-0002QT-Px\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:01:26 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34356\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvH1f-0002Q3-L9\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:01:23 -0400","from pps.filterd (m0098420.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8M5DxBk100817\n\tfor ; Fri, 22 Sep 2017 02:01:19 -0400","from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2d4pnhk3q1-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 22 Sep 2017 02:01:18 -0400","from localhost\n\tby e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 22 Sep 2017 16:01:15 +1000","from d23relay07.au.ibm.com (202.81.31.226)\n\tby e23smtp05.au.ibm.com (202.81.31.211) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tFri, 22 Sep 2017 16:01:12 +1000","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv8M61CKa18808946; Fri, 22 Sep 2017 16:01:12 +1000","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv8M614mQ020854; Fri, 22 Sep 2017 16:01:04 +1000","from abhimanyu.vnet.linux.ibm.com ([9.102.1.54])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv8M60iGg019774\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=NO); Fri, 22 Sep 2017 16:01:01 +1000"],"From":"Nikunj A Dadhania ","To":"David Gibson ","In-Reply-To":"<20170921053107.GD4998@umbus.fritz.box>","References":"<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170921053107.GD4998@umbus.fritz.box>","Date":"Fri, 22 Sep 2017 11:30:51 +0530","MIME-Version":"1.0","Content-Type":"text/plain","X-TM-AS-MML":"disable","x-cbid":"17092206-0016-0000-0000-000002657372","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092206-0017-0000-0000-000006EADB6E","Message-Id":"<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-22_01:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709220072","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, \n\tclg@kaod.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773287,"web_url":"http://patchwork.ozlabs.org/comment/1773287/","msgid":"","list_archive_url":null,"date":"2017-09-22T06:07:06","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/22/2017 08:00 AM, Nikunj A Dadhania wrote:\n> David Gibson writes:\n> \n>>>>>\n>>>>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n>>>>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n>>>>> this:\n>>>>>\n>>>>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n>>>>>\n>>>>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n>>>>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n>>>>> was 1), which is wrong as per the command-line that was provided.\n>>>>\n>>>> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n>>>> thread. If you can't supply 4 sockets you should error, but you\n>>>> shouldn't go and change the number of cores per socket.\n>>>\n>>> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n>>> case. Now looking more into it, i see that powernv has something called\n>>> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n>>\n>> Ah, yes, I see. It's probably still reasonable to keep num_chips as\n>> an internal variable, rather than using (smp_cpus / smp_cores /\n>> smp_threads) everywhere. But we shouldn't have it as a direct\n>> user-settable property, instead setting it from the -smp command line\n>> option.\n> \n> Something like the below works till num_chips=2, after that guest does\n> not boot up. This might be some limitation within the OS, Cedric might\n> have some clue.\n\nSome controllers might need some more tweaking, PSI, LPC, to elect a \nmaster one. Anyhow I don't think we want to deduce the number of chips\nfrom the number of cpus. These two figures are very different.\n\nC.\n\n> Otherwise, I see that multiple chips are created with single core having \n> single thread.\n>\n> ppc/pnv: Use num_chips for multiple sockets\n> \n> When the user does not provide the cpu topology, e.g. \"-smp 4\", machine fails to\n> initialize 4 cpus. QEMU assumes smp_threads and smp_cores both as 1. Make sure\n> that we initialize multiple chips for this.\n> \n> Remove the user-settable property num_chips from machine command line option\n> \n> Signed-off-by: Nikunj A Dadhania \n> \n> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c\n> index 9724719..fa501f9 100644\n> --- a/hw/ppc/pnv.c\n> +++ b/hw/ppc/pnv.c\n> @@ -709,7 +709,17 @@ static void ppc_powernv_init(MachineState *machine)\n> exit(1);\n> }\n> \n> + pnv->num_chips = smp_cpus / (smp_cores * smp_threads);\n> pnv->chips = g_new0(PnvChip *, pnv->num_chips);\n> +\n> + if (smp_cpus != (smp_threads * pnv->num_chips * smp_cores)) {\n> + error_report(\"cpu topology not balanced: \"\n> + \"chips (%u) * cores (%u) * threads (%u) != \"\n> + \"number of cpus (%u)\",\n> + pnv->num_chips, smp_cores, smp_threads, smp_cpus);\n> + exit(1);\n> + }\n> +\n> for (i = 0; i < pnv->num_chips; i++) {\n> char chip_name[32];\n> Object *chip = object_new(chip_typename);\n> @@ -1255,53 +1265,12 @@ static void pnv_pic_print_info(InterruptStatsProvider *obj,\n> }\n> }\n> \n> -static void pnv_get_num_chips(Object *obj, Visitor *v, const char *name,\n> - void *opaque, Error **errp)\n> -{\n> - visit_type_uint32(v, name, &POWERNV_MACHINE(obj)->num_chips, errp);\n> -}\n> -\n> -static void pnv_set_num_chips(Object *obj, Visitor *v, const char *name,\n> - void *opaque, Error **errp)\n> -{\n> - PnvMachineState *pnv = POWERNV_MACHINE(obj);\n> - uint32_t num_chips;\n> - Error *local_err = NULL;\n> -\n> - visit_type_uint32(v, name, &num_chips, &local_err);\n> - if (local_err) {\n> - error_propagate(errp, local_err);\n> - return;\n> - }\n> -\n> - /*\n> - * TODO: should we decide on how many chips we can create based\n> - * on #cores and Venice vs. Murano vs. Naples chip type etc...,\n> - */\n> - if (!is_power_of_2(num_chips) || num_chips > 4) {\n> - error_setg(errp, \"invalid number of chips: '%d'\", num_chips);\n> - return;\n> - }\n> -\n> - pnv->num_chips = num_chips;\n> -}\n> -\n> static void powernv_machine_initfn(Object *obj)\n> {\n> PnvMachineState *pnv = POWERNV_MACHINE(obj);\n> pnv->num_chips = 1;\n> }\n> \n> -static void powernv_machine_class_props_init(ObjectClass *oc)\n> -{\n> - object_class_property_add(oc, \"num-chips\", \"uint32\",\n> - pnv_get_num_chips, pnv_set_num_chips,\n> - NULL, NULL, NULL);\n> - object_class_property_set_description(oc, \"num-chips\",\n> - \"Specifies the number of processor chips\",\n> - NULL);\n> -}\n> -\n> static void powernv_machine_class_init(ObjectClass *oc, void *data)\n> {\n> MachineClass *mc = MACHINE_CLASS(oc);\n> @@ -1321,8 +1290,6 @@ static void powernv_machine_class_init(ObjectClass *oc, void *data)\n> xic->ics_get = pnv_ics_get;\n> xic->ics_resend = pnv_ics_resend;\n> ispc->print_info = pnv_pic_print_info;\n> -\n> - powernv_machine_class_props_init(oc);\n> }\n> \n> static const TypeInfo powernv_machine_info = {\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz31R2Slxz9sBd\n\tfor ;\n\tFri, 22 Sep 2017 16:07:55 +1000 (AEST)","from localhost ([::1]:56818 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvH7x-0003zC-Eh\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 02:07:53 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48468)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvH7T-0003xo-86\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:07:24 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvH7O-0006SD-9r\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:07:23 -0400","from 8.mo179.mail-out.ovh.net ([46.105.75.26]:37083)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dvH7N-0006RT-Vs\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 02:07:18 -0400","from player690.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo179.mail-out.ovh.net (Postfix) with ESMTP id 42C6162804\n\tfor ; Fri, 22 Sep 2017 08:07:15 +0200 (CEST)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player690.ha.ovh.net (Postfix) with ESMTPSA id 9F9B5540086;\n\tFri, 22 Sep 2017 08:07:07 +0200 (CEST)"],"To":"Nikunj A Dadhania ,\n\tDavid Gibson ","References":"<20170919082421.GU27153@umbus>\n\t<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170921053107.GD4998@umbus.fritz.box>\n\t<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"","Date":"Fri, 22 Sep 2017 08:07:06 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Ovh-Tracer-Id":"12146489674195569521","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrieefgdduudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"46.105.75.26","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773434,"web_url":"http://patchwork.ozlabs.org/comment/1773434/","msgid":"<20170922100934.GF4998@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-22T10:09:34","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Thu, Sep 21, 2017 at 09:42:26AM +0200, Igor Mammedov wrote:\n> On Thu, 21 Sep 2017 08:04:55 +0200\n> Cédric Le Goater wrote:\n> \n> > On 09/21/2017 05:54 AM, Nikunj A Dadhania wrote:\n> > > David Gibson writes:\n> > > \n> > >> On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote: \n> > >>> David Gibson writes:\n> > >>> \n> > >>>> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote: \n> > >>>>> David Gibson writes:\n> > >>>>> \n> > >>>>>> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote: \n> > >>>>>>> David Gibson writes:\n> > >>>>>>> \n> > >>>>>>>> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote: \n> > >>>>>>>>> David Gibson writes:\n> > >>>>>>>>> \n> > >>>>>>>>>> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote: \n> > >>>>>>>>>>> David Gibson writes:\n> > >>>>>>>>>>> \n> > >>>>>>>>>>>> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote: \n> > >>>>>>>>>>>>> David Gibson writes:\n> > >>>>>>>>>>>>> \n> > >>>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>>> I thought, I am doing the same here for PowerNV, number of online cores\n> > >>>>>>>>>>>>>>> is equal to initial online vcpus / threads per core\n> > >>>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>>> int boot_cores_nr = smp_cpus / smp_threads;\n> > >>>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>>> Only difference that I see in PowerNV is that we have multiple chips\n> > >>>>>>>>>>>>>>> (max 2, at the moment)\n> > >>>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips); \n> > >>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>> This doesn't make sense to me. Cores per chip should *always* equal\n> > >>>>>>>>>>>>>> smp_cores, you shouldn't need another calculation for it.\n> > >>>>>>>>>>>>>> \n> > >>>>>>>>>>>>>>> And in case user has provided sane smp_cores, we use it. \n> > >>>>>>>>>>>>>>\n> > >>>>>>>>>>>>>> If smp_cores isn't sane, you should simply reject it, not try to fix\n> > >>>>>>>>>>>>>> it. That's just asking for confusion. \n> > >>>>>>>>>>>>>\n> > >>>>>>>>>>>>> This is the case where the user does not provide a topology(which is a\n> > >>>>>>>>>>>>> valid scenario), not sure we should reject it. So qemu defaults\n> > >>>>>>>>>>>>> smp_cores/smt_threads to 1. I think it makes sense to over-ride. \n> > >>>>>>>>>>>>\n> > >>>>>>>>>>>> If you can find a way to override it by altering smp_cores when it's\n> > >>>>>>>>>>>> not explicitly specified, then ok. \n> > >>>>>>>>>>>\n> > >>>>>>>>>>> Should I change the global smp_cores here as well ? \n> > >>>>>>>>>>\n> > >>>>>>>>>> I'm pretty uneasy with that option. \n> > >>>>>>>>>\n> > >>>>>>>>> Me too.\n> > >>>>>>>>> \n> > >>>>>>>>>> It would take a fair bit of checking to ensure that changing smp_cores\n> > >>>>>>>>>> is safe here. An easier to verify option would be to make the generic\n> > >>>>>>>>>> logic which splits up an unspecified -smp N into cores and sockets\n> > >>>>>>>>>> more flexible, possibly based on machine options for max values.\n> > >>>>>>>>>>\n> > >>>>>>>>>> That might still be more trouble than its worth. \n> > >>>>>>>>>\n> > >>>>>>>>> I think the current approach is the simplest and less intrusive, as we\n> > >>>>>>>>> are handling a case where user has not bothered to provide a detailed\n> > >>>>>>>>> topology, the best we can do is create single threaded cores equal to\n> > >>>>>>>>> number of cores. \n> > >>>>>>>>\n> > >>>>>>>> No, sorry. Having smp_cores not correspond to the number of cores per\n> > >>>>>>>> chip in all cases is just not ok. Add an error message if the\n> > >>>>>>>> topology isn't workable for powernv by all means. But users having to\n> > >>>>>>>> use a longer command line is better than breaking basic assumptions\n> > >>>>>>>> about what numbers reflect what topology. \n> > >>>>>>>\n> > >>>>>>> Sorry to ask again, as I am still not convinced, we do similar\n> > >>>>>>> adjustment in spapr where the user did not provide the number of cores,\n> > >>>>>>> but qemu assumes them as single threaded cores and created\n> > >>>>>>> cores(boot_cores_nr) that were not same as smp_cores ? \n> > >>>>>>\n> > >>>>>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n> > >>>>>> topology, and it certainly doesn't assume they're single threaded. \n> > >>>>>\n> > >>>>> When we start a TCG guest and user provides following commandline, e.g.\n> > >>>>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> > >>>>> with 4 cores, each having 1 thread. \n> > >>>>\n> > >>>> Ok.. and what's the problem with that behaviour on powernv? \n> > >>>\n> > >>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> > >>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> > >>> this:\n> > >>>\n> > >>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> > >>>\n> > >>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> > >>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> > >>> was 1), which is wrong as per the command-line that was provided. \n> > >>\n> > >> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> > >> thread. If you can't supply 4 sockets you should error, but you\n> > >> shouldn't go and change the number of cores per socket. \n> > > \n> > > OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> > > case. Now looking more into it, i see that powernv has something called\n> > > \"num_chips\", isnt this same as sockets ? Do we need num_chips separately? \n> > \n> > yes that would do for cpus, but how do we retrieve the number of \n> > sockets ? I don't see a smp_sockets. \n> I'd suggest to rewrite QEMU again :)\n> \n> more exactly, -smp parsing is global and sometimes doesn't suite\n> target device model/machine.\n> Idea was to make it's options machine properties to get rid of globals\n> and then let leaf machine redefine parsing behaviour.\n> here is Drew's take on it:\n> \n> [Qemu-devel] [PATCH RFC 00/16] Rework SMP parameters\n> https://www.mail-archive.com/qemu-devel@nongnu.org/msg376961.html\n> \n> considering there weren't pressing need, the series has been pushed\n> to the end of TODO list. Maybe you can revive it and make work for\n> pnv and other machines.\n\nRight, making the core smp parsing more flexible might be good.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"f445wrWf\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz8Tj0WYzz9t16\n\tfor ;\n\tFri, 22 Sep 2017 20:14:15 +1000 (AEST)","from localhost ([::1]:57756 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvKyL-0002Xd-1f\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 06:14:13 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49927)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvKxe-0002Ww-R6\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:32 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvKxc-00022N-Qq\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:30 -0400","from ozlabs.org ([2401:3900:2:1::2]:38001)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvKxc-00020C-5m; Fri, 22 Sep 2017 06:13:28 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xz8Sf6zp6z9t16; Fri, 22 Sep 2017 20:13:22 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1506075202;\n\tbh=BGg0l4oQ9FN1d1R2MLdPQ2jmwYr+fiy4zczCX8aGItA=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=f445wrWfIqvA7GrolqL6c50XF7qpnP38QeW0hsxgHw53JCeWYhEJ/6nbWMFqFT2HN\n\t96eH/TTHRwQfYCGyeK1DzULgNgxtWuI+7EZEixt0Eh7ntBqbAWGue87AuGy2kiPk0M\n\tXiNxydXECOGLEg9T4OW1d2QD/bkA4ZIzPV9kpU+E=","Date":"Fri, 22 Sep 2017 20:09:34 +1000","From":"David Gibson ","To":"Igor Mammedov ","Message-ID":"<20170922100934.GF4998@umbus.fritz.box>","References":"<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t\n\t<20170921094226.0e4c4ac6@nial.brq.redhat.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"w3uUfsyyY1Pqa/ej\"","Content-Disposition":"inline","In-Reply-To":"<20170921094226.0e4c4ac6@nial.brq.redhat.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"bharata@linux.vnet.ibm.com, qemu-ppc@nongnu.org, =?iso-8859-1?q?C=E9dr?=\n\t=?iso-8859-1?q?ic?= Le Goater ,\n\tNikunj A Dadhania , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773435,"web_url":"http://patchwork.ozlabs.org/comment/1773435/","msgid":"<20170922100858.GE4998@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-22T10:08:58","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Thu, Sep 21, 2017 at 08:04:55AM +0200, Cédric Le Goater wrote:\n> On 09/21/2017 05:54 AM, Nikunj A Dadhania wrote:\n> > David Gibson writes:\n> > \n> >> On Wed, Sep 20, 2017 at 12:48:55PM +0530, Nikunj A Dadhania wrote:\n> >>> David Gibson writes:\n> >>>\n> >>>> On Wed, Sep 20, 2017 at 12:10:48PM +0530, Nikunj A Dadhania wrote:\n> >>>>> David Gibson writes:\n> >>>>>\n> >>>>>> On Wed, Sep 20, 2017 at 10:43:19AM +0530, Nikunj A Dadhania wrote:\n> >>>>>>> David Gibson writes:\n> >>>>>>>\n> >>>>>>>> On Wed, Sep 20, 2017 at 09:50:24AM +0530, Nikunj A Dadhania wrote:\n> >>>>>>>>> David Gibson writes:\n> >>>>>>>>>\n> >>>>>>>>>> On Fri, Sep 15, 2017 at 02:39:16PM +0530, Nikunj A Dadhania wrote:\n> >>>>>>>>>>> David Gibson writes:\n> >>>>>>>>>>>\n> >>>>>>>>>>>> On Fri, Sep 15, 2017 at 01:53:15PM +0530, Nikunj A Dadhania wrote:\n> >>>>>>>>>>>>> David Gibson writes:\n> >>>>>>>>>>>>>\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> I thought, I am doing the same here for PowerNV, number of online cores\n> >>>>>>>>>>>>>>> is equal to initial online vcpus / threads per core\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> int boot_cores_nr = smp_cpus / smp_threads;\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> Only difference that I see in PowerNV is that we have multiple chips\n> >>>>>>>>>>>>>>> (max 2, at the moment)\n> >>>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> cores_per_chip = smp_cpus / (smp_threads * pnv->num_chips);\n> >>>>>>>>>>>>>>\n> >>>>>>>>>>>>>> This doesn't make sense to me. Cores per chip should *always* equal\n> >>>>>>>>>>>>>> smp_cores, you shouldn't need another calculation for it.\n> >>>>>>>>>>>>>>\n> >>>>>>>>>>>>>>> And in case user has provided sane smp_cores, we use it.\n> >>>>>>>>>>>>>>\n> >>>>>>>>>>>>>> If smp_cores isn't sane, you should simply reject it, not try to fix\n> >>>>>>>>>>>>>> it. That's just asking for confusion.\n> >>>>>>>>>>>>>\n> >>>>>>>>>>>>> This is the case where the user does not provide a topology(which is a\n> >>>>>>>>>>>>> valid scenario), not sure we should reject it. So qemu defaults\n> >>>>>>>>>>>>> smp_cores/smt_threads to 1. I think it makes sense to over-ride.\n> >>>>>>>>>>>>\n> >>>>>>>>>>>> If you can find a way to override it by altering smp_cores when it's\n> >>>>>>>>>>>> not explicitly specified, then ok.\n> >>>>>>>>>>>\n> >>>>>>>>>>> Should I change the global smp_cores here as well ?\n> >>>>>>>>>>\n> >>>>>>>>>> I'm pretty uneasy with that option.\n> >>>>>>>>>\n> >>>>>>>>> Me too.\n> >>>>>>>>>\n> >>>>>>>>>> It would take a fair bit of checking to ensure that changing smp_cores\n> >>>>>>>>>> is safe here. An easier to verify option would be to make the generic\n> >>>>>>>>>> logic which splits up an unspecified -smp N into cores and sockets\n> >>>>>>>>>> more flexible, possibly based on machine options for max values.\n> >>>>>>>>>>\n> >>>>>>>>>> That might still be more trouble than its worth.\n> >>>>>>>>>\n> >>>>>>>>> I think the current approach is the simplest and less intrusive, as we\n> >>>>>>>>> are handling a case where user has not bothered to provide a detailed\n> >>>>>>>>> topology, the best we can do is create single threaded cores equal to\n> >>>>>>>>> number of cores.\n> >>>>>>>>\n> >>>>>>>> No, sorry. Having smp_cores not correspond to the number of cores per\n> >>>>>>>> chip in all cases is just not ok. Add an error message if the\n> >>>>>>>> topology isn't workable for powernv by all means. But users having to\n> >>>>>>>> use a longer command line is better than breaking basic assumptions\n> >>>>>>>> about what numbers reflect what topology.\n> >>>>>>>\n> >>>>>>> Sorry to ask again, as I am still not convinced, we do similar\n> >>>>>>> adjustment in spapr where the user did not provide the number of cores,\n> >>>>>>> but qemu assumes them as single threaded cores and created\n> >>>>>>> cores(boot_cores_nr) that were not same as smp_cores ?\n> >>>>>>\n> >>>>>> What? boot_cores_nr has absolutely nothing to do with adjusting the\n> >>>>>> topology, and it certainly doesn't assume they're single threaded.\n> >>>>>\n> >>>>> When we start a TCG guest and user provides following commandline, e.g.\n> >>>>> \"-smp 4\", smt_threads is set to 1 by default in vl.c. So the guest boots\n> >>>>> with 4 cores, each having 1 thread.\n> >>>>\n> >>>> Ok.. and what's the problem with that behaviour on powernv?\n> >>>\n> >>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> >>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> >>> this:\n> >>>\n> >>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> >>>\n> >>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> >>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> >>> was 1), which is wrong as per the command-line that was provided.\n> >>\n> >> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> >> thread. If you can't supply 4 sockets you should error, but you\n> >> shouldn't go and change the number of cores per socket.\n> > \n> > OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> > case. Now looking more into it, i see that powernv has something called\n> > \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n> \n> yes that would do for cpus, but how do we retrieve the number of \n> sockets ? I don't see a smp_sockets. \n\n\t# sockets = smp_cpus / smp_threads / smp_cores\n\nOr, if you want the maximum possible number of sockets (for a fully\npopulated system)\n\t# sockets = max_cpus / smp_threads / smp_cores\n\t\n\n> If we start looking at such issues, we should also take into account \n> memory distribution :\n> \n> -numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n> \n> would allow us to define a set of cpus per node, cpus should be evenly \n> distributed on the nodes though, and also define memory per node, but \n> some nodes could be without memory.\n\nI don't really see what that has to do with anything. We already have\nways to assign memory or cpus to specific nodes if we want.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"Z/4LVP/U\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz8Tj0Wj5z9t3w\n\tfor ;\n\tFri, 22 Sep 2017 20:14:15 +1000 (AEST)","from localhost ([::1]:57757 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvKyK-0002Xl-CP\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 06:14:12 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49921)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvKxe-0002Wv-HB\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:32 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvKxc-00022U-Tb\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:30 -0400","from ozlabs.org ([2401:3900:2:1::2]:42297)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvKxc-0001zf-AS; Fri, 22 Sep 2017 06:13:28 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xz8Sf4HXJz9sP1; Fri, 22 Sep 2017 20:13:22 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1506075202;\n\tbh=hTF3YITnRRU43HEYUMP+98QsQ4RaQbsGUTQeZbd4xlA=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Z/4LVP/UMoSVH3L/kHgG4OPaNVSrO/CgePRX1WH7TEcefYi7Dx0AftJvnSNF9stjL\n\t12/avHCwo3LdIM4TVc5sILI3ysqoI4OLjyG3deyFGkgiR64FW55n4ssTSD/1w8MGoR\n\t5vu9JiHkidd+W8egOGwmZOqOUrrpWFNOX4iahW2s=","Date":"Fri, 22 Sep 2017 20:08:58 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170922100858.GE4998@umbus.fritz.box>","References":"<871sn2hugn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920045524.GH5520@umbus.fritz.box>\n\t<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"M/SuVGWktc5uNpra\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org,\n\tNikunj A Dadhania , bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773438,"web_url":"http://patchwork.ozlabs.org/comment/1773438/","msgid":"<20170922101201.GG4998@umbus.fritz.box>","list_archive_url":null,"date":"2017-09-22T10:12:01","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":47,"url":"http://patchwork.ozlabs.org/api/people/47/","name":"David Gibson","email":"david@gibson.dropbear.id.au"},"content":"On Fri, Sep 22, 2017 at 08:07:06AM +0200, Cédric Le Goater wrote:\n> On 09/22/2017 08:00 AM, Nikunj A Dadhania wrote:\n> > David Gibson writes:\n> > \n> >>>>>\n> >>>>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n> >>>>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n> >>>>> this:\n> >>>>>\n> >>>>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n> >>>>>\n> >>>>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n> >>>>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n> >>>>> was 1), which is wrong as per the command-line that was provided.\n> >>>>\n> >>>> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n> >>>> thread. If you can't supply 4 sockets you should error, but you\n> >>>> shouldn't go and change the number of cores per socket.\n> >>>\n> >>> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n> >>> case. Now looking more into it, i see that powernv has something called\n> >>> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n> >>\n> >> Ah, yes, I see. It's probably still reasonable to keep num_chips as\n> >> an internal variable, rather than using (smp_cpus / smp_cores /\n> >> smp_threads) everywhere. But we shouldn't have it as a direct\n> >> user-settable property, instead setting it from the -smp command line\n> >> option.\n> > \n> > Something like the below works till num_chips=2, after that guest does\n> > not boot up. This might be some limitation within the OS, Cedric might\n> > have some clue.\n> \n> Some controllers might need some more tweaking, PSI, LPC, to elect a \n> master one.\n\nUh.. why?\n\n> Anyhow I don't think we want to deduce the number of chips\n> from the number of cpus. These two figures are very different.\n\nHow so? It's not totally perfect, but making a single chip correspond\nto a \"socket\" in qemu's (somewhat x86 centric) terminology is still a\npretty good match.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=gibson.dropbear.id.au\n\theader.i=@gibson.dropbear.id.au header.b=\"nS23dpcw\"; \n\tdkim-atps=neutral"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz8XQ2qLTz9sNw\n\tfor ;\n\tFri, 22 Sep 2017 20:16:38 +1000 (AEST)","from localhost ([::1]:57772 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvL0e-0004Jz-Bh\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 06:16:36 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49995)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvKxk-0002Ys-7Q\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:38 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvKxe-00023F-8B\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:13:36 -0400","from ozlabs.org ([2401:3900:2:1::2]:40741)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dvKxd-0001zv-TK; Fri, 22 Sep 2017 06:13:30 -0400","by ozlabs.org (Postfix, from userid 1007)\n\tid 3xz8Sf5VXJz9sNw; Fri, 22 Sep 2017 20:13:22 +1000 (AEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n\td=gibson.dropbear.id.au; s=201602; t=1506075202;\n\tbh=tGpCxrBeyAxRnD2yorkQJAg73Gz2D+uDSGLmUrkHLFk=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=nS23dpcwc3pwbxSgpYUPEi/wVD7Wu5IiiJKtGkfVYMS7LcPiJyP3Ew8YWXv350jrf\n\t0xF3t/Yvu/3dhYeerYe+vfNTIxhe8hBUbxR+nviuHO6NUYuWlx4PMtPGGw5Ear/3Ec\n\tcxtex6OwG38cWHfeg2hy+ocn93aApgms5xzf4i8w=","Date":"Fri, 22 Sep 2017 20:12:01 +1000","From":"David Gibson ","To":"=?iso-8859-1?q?C=E9dric?= Le Goater ","Message-ID":"<20170922101201.GG4998@umbus.fritz.box>","References":"<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170921053107.GD4998@umbus.fritz.box>\n\t<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"Qf1oXS95uex85X0R\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-detected-operating-system":"by eggs.gnu.org: Genre and OS details not\n\trecognized.","X-Received-From":"2401:3900:2:1::2","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org,\n\tNikunj A Dadhania , bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1773469,"web_url":"http://patchwork.ozlabs.org/comment/1773469/","msgid":"<8cf3e77a-e397-c082-f1a2-b6b8c6be439f@kaod.org>","list_archive_url":null,"date":"2017-09-22T10:46:58","subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","submitter":{"id":68548,"url":"http://patchwork.ozlabs.org/api/people/68548/","name":"Cédric Le Goater","email":"clg@kaod.org"},"content":"On 09/22/2017 12:12 PM, David Gibson wrote:\n> On Fri, Sep 22, 2017 at 08:07:06AM +0200, Cédric Le Goater wrote:\n>> On 09/22/2017 08:00 AM, Nikunj A Dadhania wrote:\n>>> David Gibson writes:\n>>>\n>>>>>>>\n>>>>>>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the\n>>>>>>> default value of 1 in vl.c. In powernv, we were setting nr-cores like\n>>>>>>> this:\n>>>>>>>\n>>>>>>> object_property_set_int(chip, smp_cores, \"nr-cores\", &error_fatal);\n>>>>>>>\n>>>>>>> Even when there were multiple cpus (-smp 4), when the guest boots up, we\n>>>>>>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads\n>>>>>>> was 1), which is wrong as per the command-line that was provided.\n>>>>>>\n>>>>>> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1\n>>>>>> thread. If you can't supply 4 sockets you should error, but you\n>>>>>> shouldn't go and change the number of cores per socket.\n>>>>>\n>>>>> OK, that makes sense now. And I do see that smp_cpus is 4 in the above\n>>>>> case. Now looking more into it, i see that powernv has something called\n>>>>> \"num_chips\", isnt this same as sockets ? Do we need num_chips separately?\n>>>>\n>>>> Ah, yes, I see. It's probably still reasonable to keep num_chips as\n>>>> an internal variable, rather than using (smp_cpus / smp_cores /\n>>>> smp_threads) everywhere. But we shouldn't have it as a direct\n>>>> user-settable property, instead setting it from the -smp command line\n>>>> option.\n>>>\n>>> Something like the below works till num_chips=2, after that guest does\n>>> not boot up. This might be some limitation within the OS, Cedric might\n>>> have some clue.\n>>\n>> Some controllers might need some more tweaking, PSI, LPC, to elect a \n>> master one.\n> \n> Uh.. why?\n\nthat's not true. I managed to boot a pnv machine with 4 chips/sockets \neach having 4 cpus using a 4.4.9-openpower2 skiroot kernel, from an \nopenpower firmare 1.10 I think. Recent openpower kernel must be using \nsome new features/instructions that we don't manage well in QEMU.\n\nI would need to build a kernel with more output.\n\n>> Anyhow I don't think we want to deduce the number of chips\n>> from the number of cpus. These two figures are very different.\n> \n> How so? It's not totally perfect, but making a single chip correspond\n> to a \"socket\" in qemu's (somewhat x86 centric) terminology is still a\n> pretty good match.\n\nwell, it would be good to be able to define chips with different\nnumbers of cpus. That is something will we want to do for sure.\n\nThanks,\n\nC.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz9DT0jMcz9s8J\n\tfor ;\n\tFri, 22 Sep 2017 20:47:53 +1000 (AEST)","from localhost ([::1]:57926 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dvLUs-0000kt-Lg\n\tfor incoming@patchwork.ozlabs.org; Fri, 22 Sep 2017 06:47:50 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:59719)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dvLUH-0000gj-E4\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:47:14 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dvLUE-00062W-Bz\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:47:13 -0400","from 4.mo179.mail-out.ovh.net ([46.105.36.149]:49090)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dvLUE-00061n-5p\n\tfor qemu-devel@nongnu.org; Fri, 22 Sep 2017 06:47:10 -0400","from player690.ha.ovh.net (b6.ovh.net [213.186.33.56])\n\tby mo179.mail-out.ovh.net (Postfix) with ESMTP id 6762262310\n\tfor ; Fri, 22 Sep 2017 12:47:07 +0200 (CEST)","from zorba.kaod.org (LFbn-1-2231-173.w90-76.abo.wanadoo.fr\n\t[90.76.52.173]) (Authenticated sender: postmaster@kaod.org)\n\tby player690.ha.ovh.net (Postfix) with ESMTPSA id 836F0540093;\n\tFri, 22 Sep 2017 12:46:58 +0200 (CEST)"],"To":"David Gibson ","References":"<87y3pagdg0.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920061756.GJ5520@umbus.fritz.box>\n\t<87vakdhnyn.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920065700.GO5520@umbus.fritz.box>\n\t<87poalhm74.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170920115342.GQ5520@umbus.fritz.box>\n\t<87377gpuyh.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t<20170921053107.GD4998@umbus.fritz.box>\n\t<87y3p7nugc.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>\n\t\n\t<20170922101201.GG4998@umbus.fritz.box>","From":"=?utf-8?q?C=C3=A9dric_Le_Goater?= ","Message-ID":"<8cf3e77a-e397-c082-f1a2-b6b8c6be439f@kaod.org>","Date":"Fri, 22 Sep 2017 12:46:58 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170922101201.GG4998@umbus.fritz.box>","Content-Type":"text/plain; charset=windows-1252","Content-Language":"en-US","X-Ovh-Tracer-Id":"16873580431389723505","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelledrieeggdefgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","Content-Transfer-Encoding":"quoted-printable","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"46.105.36.149","Subject":"Re: [Qemu-devel] [PATCH] ppc/pnv: fix cores per chip for multiple\n\tcpus","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"qemu-ppc@nongnu.org, qemu-devel@nongnu.org,\n\tNikunj A Dadhania , bharata@linux.vnet.ibm.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]