From nobody Tue Oct 28 01:57:55 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1516079172315766.1826410374068; Mon, 15 Jan 2018 21:06:12 -0800 (PST) Received: from localhost ([::1]:35342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebJRn-0006sP-Ar for importer@patchew.org; Tue, 16 Jan 2018 00:06:07 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebJ9j-0007zB-7q for qemu-devel@nongnu.org; Mon, 15 Jan 2018 23:47:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebJ9g-0004mV-5H for qemu-devel@nongnu.org; Mon, 15 Jan 2018 23:47:27 -0500 Received: from ozlabs.org ([103.22.144.67]:57917) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ebJ9f-0004lD-Ip; Mon, 15 Jan 2018 23:47:24 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3zLHkt1bJRz9t2c; Tue, 16 Jan 2018 15:47:17 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1516078038; bh=FTAK8DGGpVFbnaHFhXG1/EUCwpaieM2NlAZPPaoYVP4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g+Ft0pN07KQcGIokzkObw3LstGN/irNnHjuc56yiEYyyLtsBi8Rm6aF/OWkexoFlA 3aLsUwmDAZt5cyjX+iU4CZUiYqcaHHBoNyaI2DPITyBHARFo1I9rx/do+++gSdrHe9 gLu+An1wcAi/kdNCb/U/R4h7uHZe6xRGQB8N/QoY= From: David Gibson To: groug@kaod.org, joserz@linux.vnet.ibm.com, surajjs@au1.ibm.com, sam.bobroff@au1.ibm.com Date: Tue, 16 Jan 2018 15:47:13 +1100 Message-Id: <20180116044714.12571-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180116044714.12571-1-david@gibson.dropbear.id.au> References: <20180116044714.12571-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 103.22.144.67 Subject: [Qemu-devel] [PATCHv2 1/2] spapr: Allow some cases where we can't set VSMT mode in the kernel X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" At present if we require a vsmt mode that's not equal to the kernel's default, and the kernel doesn't let us change it (e.g. because it's an old kernel without support) then we always fail. But in fact we can cope with the kernel having a different vsmt as long as a) it's >=3D the actual number of vthreads/vcore (so that guest threads that are supposed to be on the same core act like it) b) it's a submultiple of the requested vsmt mode (so that guest threads spaced by the vsmt value will act like they're on different cores) Allowing this case gives us a bit more freedom to adjust the vsmt behaviour without breaking existing cases. Signed-off-by: David Gibson Reviewed-by: Greg Kurz Reviewed-by: Laurent Vivier Tested-by: Greg Kurz --- hw/ppc/spapr.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index e35214bfc3..6d3613d934 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -2314,17 +2314,29 @@ static void spapr_set_vsmt_mode(sPAPRMachineState *= spapr, Error **errp) if (kvm_enabled() && (spapr->vsmt !=3D kvm_smt)) { ret =3D kvmppc_set_smt_threads(spapr->vsmt); if (ret) { + /* Looks like KVM isn't able to change VSMT mode */ error_setg(&local_err, "Failed to set KVM's VSMT mode to %d (errno %d)", spapr->vsmt, ret); - if (!vsmt_user) { - error_append_hint(&local_err, "On PPC, a VM with %d thread= s/" - "core on a host with %d threads/core requires= " - " the use of VSMT mode %d.\n", - smp_threads, kvm_smt, spapr->vsmt); + /* We can live with that if the default one is big enough + * for the number of threads, and a submultiple of the one + * we want. In this case we'll waste some vcpu ids, but + * behaviour will be correct */ + if ((kvm_smt >=3D smp_threads) && (spapr->vsmt % kvm_smt) =3D= =3D 0) { + warn_report_err(local_err); + local_err =3D NULL; + goto out; + } else { + if (!vsmt_user) { + error_append_hint(&local_err, + "On PPC, a VM with %d threads/core" + " on a host with %d threads/core" + " requires the use of VSMT mode %d.\= n", + smp_threads, kvm_smt, spapr->vsmt); + } + kvmppc_hint_smt_possible(&local_err); + goto out; } - kvmppc_hint_smt_possible(&local_err); - goto out; } } /* else TCG: nothing to do currently */ --=20 2.14.3