From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIbl3-0005B9-LX for qemu-devel@nongnu.org; Thu, 30 Jun 2016 09:11:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIbkx-0004Ci-KD for qemu-devel@nongnu.org; Thu, 30 Jun 2016 09:11:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIbkx-0004CV-Bx for qemu-devel@nongnu.org; Thu, 30 Jun 2016 09:11:47 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 12C2B46D for ; Thu, 30 Jun 2016 13:11:47 +0000 (UTC) References: <1467289387-47575-1-git-send-email-imammedo@redhat.com> <1467289387-47575-4-git-send-email-imammedo@redhat.com> <57751536.40003@redhat.com> <20160630150102.02954c68@nial.brq.redhat.com> From: Marcel Apfelbaum Message-ID: <57751A90.9050902@redhat.com> Date: Thu, 30 Jun 2016 16:11:44 +0300 MIME-Version: 1.0 In-Reply-To: <20160630150102.02954c68@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/4] acpi: provide _PXM method for CPU devices if QEMU is started numa enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, mst@redhat.com On 06/30/2016 04:01 PM, Igor Mammedov wrote: > On Thu, 30 Jun 2016 15:48:54 +0300 > Marcel Apfelbaum wrote: > >> On 06/30/2016 03:23 PM, Igor Mammedov wrote: >>> fixes long standing issue where Linux kernel would assing >>> hotplugged CPU to 1st numa node as it discards proximity >>> for hotplugged CPUs after SRAT is parsed. >>> >>> Signed-off-by: Igor Mammedov >>> --- >>> hw/acpi/cpu.c | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c >>> index c13b65c..d9cf3ee 100644 >>> --- a/hw/acpi/cpu.c >>> +++ b/hw/acpi/cpu.c >>> @@ -4,6 +4,7 @@ >>> #include "qapi/error.h" >>> #include "qapi-event.h" >>> #include "trace.h" >>> +#include "sysemu/numa.h" >>> >>> #define ACPI_CPU_HOTPLUG_REG_LEN 12 >>> #define ACPI_CPU_SELECTOR_OFFSET_WR 0 >>> @@ -503,6 +504,7 @@ void build_cpus_aml(Aml *table, MachineState *mac= hine, CPUHotplugFeatures opts, >>> >>> /* build Processor object for each processor */ >>> for (i =3D 0; i < arch_ids->len; i++) { >>> + int j; >>> Aml *dev; >>> Aml *uid =3D aml_int(i); >>> GArray *madt_buf =3D g_array_new(0, 1, 1); >>> @@ -546,6 +548,13 @@ void build_cpus_aml(Aml *table, MachineState *ma= chine, CPUHotplugFeatures opts, >>> aml_arg(1), aml_arg(2)) >>> ); >>> aml_append(dev, method); >>> + >>> + for (j =3D 0; j < nb_numa_nodes; j++) { >>> + if (test_bit(i, numa_info[j].node_cpu)) { >>> + aml_append(dev, aml_name_decl("_PXM", aml_int(j)= )); >>> + } >>> + } >>> + >>> aml_append(cpus_dev, dev); >>> } >>> } >>> >> >> I would add, at least in the commit message, a pointer to the ACPI spe= c: >> >> ACPI 5.0 (6.2.13) >> ----------------- >> If the Local APIC ID / Local SAPIC ID / Local x2APIC ID of a dynamical= ly added processor is not >> present in the System Resource Affinity Table (SRAT), a _PXM object mu= st exist for the >> processor=E2=80=99s device or one of its ancestors in the ACPI Namespa= ce. >> >> >> I suppose we don't have the APIC id in SRAT for all possible CPUs, so = it OK. > we have entries for possible CPUs in SRAT and commit says that Linux di= scards it, > hence we need to add _PXM to CPU objects. So broken linux handling woul= d put > hotplugged CPUs into corrected nodes. > OK, so the commit message was misleading: "Fixes" :) Just flip "Fix" with "Workaround for... " > To fix it on linux side, ACPI part probably would need to be refactored= to store > parsed tables info somewhere else, so it would be available past boot t= ime > (not a small undertaking) I'd say. Maybe we should at least report it to the right mailing list. > While fixing it on QEMU side is easy and works well even for currently = released > kernels. > I have nothing against this approach. Thanks, Marcel > >> >> >> Reviewed-by: Marcel Apfelbaum > Thanks! > >> >> Thanks, >> Marcel >