From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atmAt-0003FI-Ev for qemu-devel@nongnu.org; Fri, 22 Apr 2016 21:15:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atmAq-0001dO-83 for qemu-devel@nongnu.org; Fri, 22 Apr 2016 21:15:55 -0400 Message-ID: <571ACB24.2010109@huawei.com> Date: Sat, 23 Apr 2016 09:08:52 +0800 From: Shannon Zhao MIME-Version: 1.0 References: <1461219834-10416-1-git-send-email-zhaoshenglong@huawei.com> <1461219834-10416-6-git-send-email-zhaoshenglong@huawei.com> <20160422132605.gjyuda3magcoktyf@hawk.localdomain> In-Reply-To: <20160422132605.gjyuda3magcoktyf@hawk.localdomain> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 5/5] hw/arm/virt-acpi-build: Generate SRAT table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: qemu-arm@nongnu.org, peter.maydell@linaro.org, qemu-devel@nongnu.org, david.daney@cavium.com, peter.huangpeng@huawei.com, shannon.zhao@linaro.org, imammedo@redhat.com On 2016/4/22 21:26, Andrew Jones wrote: >> + core->flags = cpu_to_le32(1); >> > + } >> > + g_free(cpu_node); >> > + >> > + mem_base = guest_info->memmap[VIRT_MEM].base; >> > + for (i = 0; i < nb_numa_nodes; ++i) { >> > + mem_len = numa_info[i].node_mem; >> > + numamem = acpi_data_push(table_data, sizeof *numamem); >> > + numamem->type = ACPI_SRAT_MEMORY; >> > + numamem->length = sizeof(*numamem); >> > + memset(numamem->proximity, 0, 4); >> > + numamem->proximity[0] = i; > This is weird (but I see x86 does it too). The spec says proximity is > "Integer that represents the proximity domain to which the processor > belongs", and its 4 bytes. So why doesn't the structure define it as > a uint32_t and then we'd just do > > numamem->proximity = cpu_to_le32(i); > > (adding Igor) > >> > + numamem->flags = cpu_to_le32(1); >> > + numamem->base_addr = cpu_to_le64(mem_base); >> > + numamem->range_length = cpu_to_le64(mem_len); > How about moving acpi_build_srat_memory from hw/i386/acpi-build.c to > somewhere in hw/acpi and reusing it? > Good point! Will do that. Thanks, -- Shannon