From patchwork Fri Jan 29 16:52:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Igor Mammedov X-Patchwork-Id: 8164931 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 0E47C9F38B for ; Fri, 29 Jan 2016 16:52:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 565BB20253 for ; Fri, 29 Jan 2016 16:52:38 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 89617200C1 for ; Fri, 29 Jan 2016 16:52:37 +0000 (UTC) Received: from localhost ([::1]:35285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPCHk-0000df-Q9 for patchwork-qemu-devel@patchwork.kernel.org; Fri, 29 Jan 2016 11:52:36 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPCHb-0000dR-1q for qemu-devel@nongnu.org; Fri, 29 Jan 2016 11:52:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPCHV-0002oN-UR for qemu-devel@nongnu.org; Fri, 29 Jan 2016 11:52:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPCHV-0002nt-Ly; Fri, 29 Jan 2016 11:52:21 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E38B8CF92; Fri, 29 Jan 2016 16:52:20 +0000 (UTC) Received: from nial.brq.redhat.com (dhcp-1-118.brq.redhat.com [10.34.1.118]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0TGqHv0016763; Fri, 29 Jan 2016 11:52:17 -0500 Date: Fri, 29 Jan 2016 17:52:15 +0100 From: Igor Mammedov To: Eduardo Habkost Message-ID: <20160129175215.5b65f98c@nial.brq.redhat.com> In-Reply-To: <20160129153605.GA3869@thinpad.lan.raisama.net> References: <1453960195-15181-1-git-send-email-bharata@linux.vnet.ibm.com> <1453960195-15181-2-git-send-email-bharata@linux.vnet.ibm.com> <20160129035230.GL23043@voom.redhat.com> <20160129142418.GY3869@thinpad.lan.raisama.net> <20160129161047.426c3d8f@nial.brq.redhat.com> <20160129153605.GA3869@thinpad.lan.raisama.net> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: mjrosato@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, Bharata B Rao , pbonzini@redhat.com, nfont@linux.vnet.ibm.com, afaerber@suse.de, David Gibson Subject: Re: [Qemu-devel] [PATCH v7 01/13] machine: Don't allow CPU toplogies with partially filled cores X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, 29 Jan 2016 13:36:05 -0200 Eduardo Habkost wrote: > On Fri, Jan 29, 2016 at 04:10:47PM +0100, Igor Mammedov wrote: > > On Fri, 29 Jan 2016 12:24:18 -0200 > > Eduardo Habkost wrote: > > > > > On Fri, Jan 29, 2016 at 02:52:30PM +1100, David Gibson wrote: > > > > On Thu, Jan 28, 2016 at 11:19:43AM +0530, Bharata B Rao wrote: > > > > > Prevent guests from booting with CPU topologies that have partially > > > > > filled CPU cores or can result in partially filled CPU cores after > > > > > CPU hotplug like > > > > > > > > > > -smp 15,sockets=1,cores=4,threads=4,maxcpus=16 or > > > > > -smp 15,sockets=1,cores=4,threads=4,maxcpus=17. > > > > > > > > > > This is enforced by introducing MachineClass::validate_smp_config() > > > > > that gets called from generic SMP parsing code. Machine type versions > > > > > that want to enforce this can define this to the generic version > > > > > provided. > > > > > > > > > > Only sPAPR and PC machine types starting from version 2.6 enforce this in > > > > > this patch. > > > > > > > > > > Signed-off-by: Bharata B Rao > > > > > > > > I've been kind of lost in the back and forth about > > > > threads/cores/sockets. > > > > > > > > What, in the end, is the rationale for allowing partially filled > > > > sockets, but not partially filled cores? > > > > > > I don't think there's a good reason for that (at least for PC). > > > > > > It's easier to relax the requirements later if necessary, than > > > dealing with compatibility issues again when making the code more > > > strict. So I suggest we make validate_smp_config_generic() also > > > check if smp_cpus % (smp_threads * smp_cores) == 0. > > > > that would break exiting setups. > > Not if we do that only on newer machine classes. > validate_smp_config_generic() will be used only on *-2.6 and > newer. > > > > > > Also in case of cpu hotplug this patch will break migration > > as target QEMU might refuse starting with hotplugged CPU thread. > > This won't change older machine-types. > > But I think you are right: it can break migration on pc-2.6, too. > But: isn't migration already broken when creating other sets of > CPUs that can't represented using -smp? > > How exactly would you migrate a machine today, if you run: > > $ qemu-system-x86_64 -smp 16,sockets=2,cores=2,threads=2,maxcpus=32 > (QMP) cpu-add id=31 that's invalid topology and should exit with error at start-up, however it shouldn't be smp_cpus vs sockets,cores,threads check but rather max_cpus vs sockets,cores,threads,maxcpus check. something like this: > > > > > > Perhaps this check should be enforced per target/machine if > > arch requires it. > > It is. Please see the patch. It introduces a validate_smp_config > method. > > But we need your input to clarify if > validate_smp_config_generic() is safe for pc-2.6 too. it breaks migration as it could prevent target from starting if there is hotplugged CPUs on source side. diff --git a/vl.c b/vl.c index f043009..3afa0b6 100644 --- a/vl.c +++ b/vl.c @@ -1239,9 +1239,9 @@ static void smp_parse(QemuOpts *opts) } max_cpus = qemu_opt_get_number(opts, "maxcpus", cpus); - if (sockets * cores * threads > max_cpus) { - error_report("cpu topology: " - "sockets (%u) * cores (%u) * threads (%u) > " + if (sockets * cores * threads == max_cpus) { + error_report("invalid cpu topology: " + "sockets (%u) * cores (%u) * threads (%u) not equal " "maxcpus (%u)", sockets, cores, threads, max_cpus); exit(1);