From nobody Wed Nov 27 07:45:42 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=linux.intel.com ARC-Seal: i=1; a=rsa-sha256; t=1700206868; cv=none; d=zohomail.com; s=zohoarc; b=J8+Kt69ETdUF765d+9Cl7xqUjrCX8A4K7loD5mGUhqXFwe2N/R7sMKAh0zalJ6xl+6Qy+yvPucUAMhFHXlOYo8zzrcpVmJfu84Iw9eZGEs8V0ozuIY8u/+FS6AH5iBth5nsYs756YFSoQ3XRsxaR6cghCqB74C2Nq3475wq9Gyw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1700206868; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=l+Zi8dnQsAd6zPjWqYFT1JsW60Va5n7xqQKljeJJRoY=; b=h3YME4+dw+c7xacEPmW0+0jPBlii5GkuNebxfzduVCgFV17mJcCwKRuUmW1bZQ7IhKg1Snkd8lSXq20EsHr54Jw7ZLDginYBzl+wACqvsDzJD3UcW+tph3zCawnwAuqwPii7QuEnFDbWkVzRJJ/yQVJRaXgmnjHMLuIKbG4oWWk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1700206868249563.2382564011691; Thu, 16 Nov 2023 23:41:08 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3tSJ-00054H-8A; Fri, 17 Nov 2023 02:39:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3tSH-00051Q-24 for qemu-devel@nongnu.org; Fri, 17 Nov 2023 02:39:57 -0500 Received: from mgamail.intel.com ([134.134.136.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3tSA-0007Hk-6l for qemu-devel@nongnu.org; Fri, 17 Nov 2023 02:39:55 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Nov 2023 23:39:47 -0800 Received: from liuzhao-optiplex-7080.sh.intel.com ([10.239.160.36]) by fmsmga002.fm.intel.com with ESMTP; 16 Nov 2023 23:39:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700206790; x=1731742790; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ru+xsMo5O18Ysv5/OaA6hVZFHETPTpuNOeacSlFbQ4A=; b=RTH7qHoi/b9W2i3KrpVlx1bo4pg5GHo+b/9L63YdGdDp/0l5vs97OLxH v4dX4s6C6VZNCPiZlWqTqGvhvRASDkR6NAUcHII5SKDBhA6O/mMiX8bz6 hnQLKjI3+hviJHkBOJTIKoMaIQqMLFwjj3w8ke+rgAS15/yarh1ohVpRm mbShlJ8BLWye9M5o2uVT5L9IS0kavT7QIwlPcsQ7TPzVquyUDb0vQgM2x xLlLc/nC0bkxdmsGQGOhg1eA8gPqB6ZHaqbIVCDrysA3C5HEDTwfLn8C9 t9/RK3oayHwqgP/bLWC52kE5125nwPX06XLLpUzbUtMzffxuclGvZY2ft Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10896"; a="395180334" X-IronPort-AV: E=Sophos;i="6.04,206,1695711600"; d="scan'208";a="395180334" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10896"; a="883042711" X-IronPort-AV: E=Sophos;i="6.04,206,1695711600"; d="scan'208";a="883042711" From: Zhao Liu To: Eduardo Habkost , Marcel Apfelbaum , "Michael S . Tsirkin" , Richard Henderson , Paolo Bonzini , Marcelo Tosatti Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Zhenyu Wang , Zhuocheng Ding , Babu Moger , Yongwei Ma , Zhao Liu Subject: [PATCH v6 06/16] i386: Introduce module-level cpu topology to CPUX86State Date: Fri, 17 Nov 2023 15:50:56 +0800 Message-Id: <20231117075106.432499-7-zhao1.liu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231117075106.432499-1-zhao1.liu@linux.intel.com> References: <20231117075106.432499-1-zhao1.liu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: none client-ip=134.134.136.65; envelope-from=zhao1.liu@linux.intel.com; helo=mgamail.intel.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1700206870316100003 Content-Type: text/plain; charset="utf-8" From: Zhuocheng Ding smp command has the "clusters" parameter but x86 hasn't supported that level. "cluster" is a CPU topology level concept above cores, in which the cores may share some resources (L2 cache or some others like L3 cache tags, depending on the Archs) [1][2]. For x86, the resource shared by cores at the cluster level is mainly the L2 cache. However, using cluster to define x86's L2 cache topology will cause the compatibility problem: Currently, x86 defaults that the L2 cache is shared in one core, which actually implies a default setting "cores per L2 cache is 1" and therefore implicitly defaults to having as many L2 caches as cores. For example (i386 PC machine): -smp 16,sockets=3D2,dies=3D2,cores=3D2,threads=3D2,maxcpus=3D16 (*) Considering the topology of the L2 cache, this (*) implicitly means "1 core per L2 cache" and "2 L2 caches per die". If we use cluster to configure L2 cache topology with the new default setting "clusters per L2 cache is 1", the above semantics will change to "2 cores per cluster" and "1 cluster per L2 cache", that is, "2 cores per L2 cache". So the same command (*) will cause changes in the L2 cache topology, further affecting the performance of the virtual machine. Therefore, x86 should only treat cluster as a cpu topology level and avoid using it to change L2 cache by default for compatibility. "cluster" in smp is the CPU topology level which is between "core" and die. For x86, the "cluster" in smp is corresponding to the module level [2], which is above the core level. So use the "module" other than "cluster" in i386 code. And please note that x86 already has a cpu topology level also named "cluster" [3], this level is at the upper level of the package. Here, the cluster in x86 cpu topology is completely different from the "clusters" as the smp parameter. After the module level is introduced, the cluster as the smp parameter will actually refer to the module level of x86. [1]: 864c3b5c32f0 ("hw/core/machine: Introduce CPU cluster topology support= ") [2]: Yanan's comment about "cluster", https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg04051.html [3]: SDM, vol.3, ch.9, 9.9.1 Hierarchical Mapping of Shared Resources. Signed-off-by: Zhuocheng Ding Co-developed-by: Zhao Liu Signed-off-by: Zhao Liu Tested-by: Babu Moger Tested-by: Yongwei Ma Acked-by: Michael S. Tsirkin --- Changes since v1: * The background of the introduction of the "cluster" parameter and its exact meaning were revised according to Yanan's explanation. (Yanan) --- hw/i386/x86.c | 1 + target/i386/cpu.c | 1 + target/i386/cpu.h | 5 +++++ 3 files changed, 7 insertions(+) diff --git a/hw/i386/x86.c b/hw/i386/x86.c index b3d054889bba..24628c1d2f73 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -306,6 +306,7 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev, init_topo_info(&topo_info, x86ms); =20 env->nr_dies =3D ms->smp.dies; + env->nr_modules =3D ms->smp.clusters; =20 /* * If APIC ID is not set, diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 1713499c44cd..f600c0ee9df1 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -7698,6 +7698,7 @@ static void x86_cpu_initfn(Object *obj) CPUX86State *env =3D &cpu->env; =20 env->nr_dies =3D 1; + env->nr_modules =3D 1; =20 object_property_add(obj, "feature-words", "X86CPUFeatureWordInfo", x86_cpu_get_feature_words, diff --git a/target/i386/cpu.h b/target/i386/cpu.h index a214d056ac4b..da58d41c9969 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1904,6 +1904,11 @@ typedef struct CPUArchState { =20 /* Number of dies within this CPU package. */ unsigned nr_dies; + /* + * Number of modules within this CPU package. + * Module level in x86 cpu topology is corresponding to smp.clusters. + */ + unsigned nr_modules; } CPUX86State; =20 struct kvm_msrs; --=20 2.34.1