From patchwork Tue Jun 22 09:34:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "wangyanan (Y)" X-Patchwork-Id: 1495505 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4G8LxM6YPPz9s24 for ; Tue, 22 Jun 2021 19:40:54 +1000 (AEST) Received: from localhost ([::1]:36422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvctm-0007lW-5o for incoming@patchwork.ozlabs.org; Tue, 22 Jun 2021 05:40:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvcns-00039x-2q; Tue, 22 Jun 2021 05:34:44 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:2179) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvcni-00032Q-L2; Tue, 22 Jun 2021 05:34:43 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4G8LjB1vD7z70y7; Tue, 22 Jun 2021 17:30:22 +0800 (CST) Received: from dggpemm500023.china.huawei.com (7.185.36.83) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 22 Jun 2021 17:34:27 +0800 Received: from DESKTOP-TMVL5KK.china.huawei.com (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 22 Jun 2021 17:34:26 +0800 From: Yanan Wang To: Peter Maydell , Andrew Jones , Paolo Bonzini , "Michael S . Tsirkin" , Igor Mammedov , Shannon Zhao , Alistair Francis , David Gibson , , Subject: [RFC PATCH v4 5/7] hw/arm/virt: Add cpu-map to device tree Date: Tue, 22 Jun 2021 17:34:11 +0800 Message-ID: <20210622093413.13360-6-wangyanan55@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 In-Reply-To: <20210622093413.13360-1-wangyanan55@huawei.com> References: <20210622093413.13360-1-wangyanan55@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Received-SPF: pass client-ip=45.249.212.189; envelope-from=wangyanan55@huawei.com; helo=szxga03-in.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Barry Song , Yanan Wang , prime.zeng@hisilicon.com, wanghaibin.wang@huawei.com, yuzenghui@huawei.com, yangyicong@huawei.com, zhukeqian1@huawei.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Andrew Jones Support device tree CPU topology descriptions. In accordance with the Devicetree Specification, the Linux Doc "arm/cpus.yaml" requires that cpus and cpu nodes in the DT are present. And we have already met the requirement by generating /cpus/cpu@* nodes for members within ms->smp.cpus. Accordingly, we should also create subnodes in cpu-map for the present cpus, each of which relates to an unique cpu node. The Linux Doc "cpu/cpu-topology.txt" states that the hierarchy of CPUs in a SMP system is defined through four entities and they are socket/cluster/core/thread. It is also required that a socket node's child nodes must be one or more cluster nodes. Given that currently we are only provided with information of socket/core/thread, we assume there is one cluster child node in each socket node when creating cpu-map. Signed-off-by: Andrew Jones Co-developed-by: Yanan Wang Signed-off-by: Yanan Wang --- hw/arm/virt.c | 58 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 10 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index f29d796f3f..645ce7d260 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -355,17 +355,17 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms) int smp_cpus = ms->smp.cpus; /* - * From Documentation/devicetree/bindings/arm/cpus.txt - * On ARM v8 64-bit systems value should be set to 2, - * that corresponds to the MPIDR_EL1 register size. - * If MPIDR_EL1[63:32] value is equal to 0 on all CPUs - * in the system, #address-cells can be set to 1, since - * MPIDR_EL1[63:32] bits are not used for CPUs - * identification. + * See Linux Documentation/devicetree/bindings/arm/cpus.yaml + * On ARM v8 64-bit systems value should be set to 2, + * that corresponds to the MPIDR_EL1 register size. + * If MPIDR_EL1[63:32] value is equal to 0 on all CPUs + * in the system, #address-cells can be set to 1, since + * MPIDR_EL1[63:32] bits are not used for CPUs + * identification. * - * Here we actually don't know whether our system is 32- or 64-bit one. - * The simplest way to go is to examine affinity IDs of all our CPUs. If - * at least one of them has Aff3 populated, we set #address-cells to 2. + * Here we actually don't know whether our system is 32- or 64-bit one. + * The simplest way to go is to examine affinity IDs of all our CPUs. If + * at least one of them has Aff3 populated, we set #address-cells to 2. */ for (cpu = 0; cpu < smp_cpus; cpu++) { ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(cpu)); @@ -408,8 +408,46 @@ static void fdt_add_cpu_nodes(const VirtMachineState *vms) ms->possible_cpus->cpus[cs->cpu_index].props.node_id); } + if (ms->expose_cpu_topology) { + qemu_fdt_setprop_cell(ms->fdt, nodename, "phandle", + qemu_fdt_alloc_phandle(ms->fdt)); + } + g_free(nodename); } + + if (ms->expose_cpu_topology) { + /* + * See Linux Documentation/devicetree/bindings/cpu/cpu-topology.txt + * In a SMP system, the hierarchy of CPUs is defined through four + * entities that are used to describe the layout of physical CPUs + * in the system: socket/cluster/core/thread. + */ + qemu_fdt_add_subnode(ms->fdt, "/cpus/cpu-map"); + + for (cpu = smp_cpus - 1; cpu >= 0; cpu--) { + char *cpu_path = g_strdup_printf("/cpus/cpu@%d", cpu); + char *map_path; + + if (ms->smp.threads > 1) { + map_path = g_strdup_printf( + "/cpus/cpu-map/%s%d/cluster0/%s%d/%s%d", + "socket", cpu / (ms->smp.cores * ms->smp.threads), + "core", (cpu / ms->smp.threads) % ms->smp.cores, + "thread", cpu % ms->smp.threads); + } else { + map_path = g_strdup_printf( + "/cpus/cpu-map/%s%d/cluster0/%s%d", + "socket", cpu / ms->smp.cores, + "core", cpu % ms->smp.cores); + } + qemu_fdt_add_path(ms->fdt, map_path); + qemu_fdt_setprop_phandle(ms->fdt, map_path, "cpu", cpu_path); + + g_free(map_path); + g_free(cpu_path); + } + } } static void fdt_add_its_gic_node(VirtMachineState *vms)