From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atsXJ-0004fa-2j for qemu-devel@nongnu.org; Sat, 23 Apr 2016 04:03:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atsXF-0001EX-ST for qemu-devel@nongnu.org; Sat, 23 Apr 2016 04:03:29 -0400 Message-ID: <571B2C2D.1070806@huawei.com> Date: Sat, 23 Apr 2016 16:02:53 +0800 From: Shannon Zhao MIME-Version: 1.0 References: <1461219834-10416-1-git-send-email-zhaoshenglong@huawei.com> <1461219834-10416-4-git-send-email-zhaoshenglong@huawei.com> <20160422124842.uhskszmlsn6v53c5@hawk.localdomain> <571ACCDB.20800@huawei.com> <20160423074542.xhwqjwfaq74kt7br@hawk.localdomain> In-Reply-To: <20160423074542.xhwqjwfaq74kt7br@hawk.localdomain> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 3/5] ARM: Add numa-node-id for /memory node List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: peter.maydell@linaro.org, david.daney@cavium.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com, qemu-arm@nongnu.org, shannon.zhao@linaro.org On 2016/4/23 15:45, Andrew Jones wrote: >>>> @@ -456,14 +460,39 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo, >>>> > >> goto fail; >>>> > >> } >>>> > >> >>>> > >> + mem_len = (nb_numa_nodes > 0) ? numa_info[0].node_mem : binfo->ram_size; >>>> > >> rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg", >>> > > >>> > > So node0's memory node will still be called '/memory' instead of >>> > > '/memory@addr' like the other nodes? Shouldn't we change it too? >>> > > >> > Previously I deleted the /memory node creation codes in virt.c and >> > create here, but that will cause other boards booting fail since >> > load_dtb() is a common function. So to avoid more changes to other >> > files, I just use current way. So is there any way to change the node >> > name after it's created in qemu? > I'm not sure if that's possible, but we could maybe use qemu_fdt_nop_node > to turn /memory into a NOP node, and then add a new one? This would be a good solution, I think. I'll update it using qemu_fdt_nop_node. Thanks, -- Shannon