From nobody Wed Nov 5 18:34:59 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1536357207776499.6384487948484; Fri, 7 Sep 2018 14:53:27 -0700 (PDT) Received: from localhost ([::1]:40415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyOgr-0002I9-5E for importer@patchew.org; Fri, 07 Sep 2018 17:53:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyOex-00004u-O8 for qemu-devel@nongnu.org; Fri, 07 Sep 2018 17:51:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyOev-0005nq-Nq for qemu-devel@nongnu.org; Fri, 07 Sep 2018 17:51:23 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:33194 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fyOev-0005mv-G0 for qemu-devel@nongnu.org; Fri, 07 Sep 2018 17:51:21 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0BC0826A81; Fri, 7 Sep 2018 21:51:21 +0000 (UTC) Received: from redhat.com (ovpn-124-199.rdu2.redhat.com [10.10.124.199]) by smtp.corp.redhat.com (Postfix) with SMTP id 7FFDD2027EA4; Fri, 7 Sep 2018 21:51:20 +0000 (UTC) Date: Fri, 7 Sep 2018 17:51:20 -0400 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Message-ID: <20180907215109.146867-2-mst@redhat.com> References: <20180907215109.146867-1-mst@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180907215109.146867-1-mst@redhat.com> X-Mutt-Fcc: =sent X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 07 Sep 2018 21:51:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 07 Sep 2018 21:51:21 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 1/7] pc: acpi: revert back to 1 SRAT entry for hotpluggable area X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Eduardo Habkost , Igor Mammedov , Paolo Bonzini , Laszlo Ersek , Richard Henderson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RDMRC_1 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Igor Mammedov Commit 10efd7e108 "pc: acpi: fix memory hotplug regression by reducing stub SRAT= entry size" attemped to fix hotplug regression introduced by 848a1cc1e "hw/acpi-build: build SRAT memory affinity structures for DIMM = devices" fixed issue for Windows/3.0+ linux kernels, however it regressed 2.6 based kernels (RHEL6) to the point where guest might crash at boot. Reason is that 2.6 kernel discards SRAT table due too small last entry which down the road leads to crashes. Hack I've tried in 10efd7e108 is also not ACPI spec compliant according to which whole possible RAM should be described in SRAT. Revert 10efd7e108 to fix regression for 2.6 based kernel= s. With 10efd7e108 reverted, I've also tried splitting SRAT table statically in different ways %/node and %/slot but Windows still fails to online 2nd pc-dimm hot-plugged into node 0 (as described in 10efd7e108) and sometimes even coldplugged pc-dimms where affected with static SRAT partitioning. The only known so far way where Windows stays happy is when we have 1 SRAT entry in the last node covering all hotplug area. Revert 848a1cc1e until we come up with a way to avoid regression on Windows with hotplug area split in several entries. Tested this with 2.6/3.0 based kernels (RHEL6/7) and WS20[08/12/12R2/16]). Signed-off-by: Igor Mammedov Acked-by: Laszlo Ersek Reviewed-by: Eduardo Habkost Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/i386/acpi-build.c | 73 ++++++++------------------------------------ 1 file changed, 12 insertions(+), 61 deletions(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index e1ee8ae9e0..1599caa7c5 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -2251,64 +2251,6 @@ build_tpm2(GArray *table_data, BIOSLinker *linker, G= Array *tcpalog) #define HOLE_640K_START (640 * KiB) #define HOLE_640K_END (1 * MiB) =20 -static void build_srat_hotpluggable_memory(GArray *table_data, uint64_t ba= se, - uint64_t len, int default_node) -{ - MemoryDeviceInfoList *info_list =3D qmp_memory_device_list(); - MemoryDeviceInfoList *info; - MemoryDeviceInfo *mi; - PCDIMMDeviceInfo *di; - uint64_t end =3D base + len, cur, size; - bool is_nvdimm; - AcpiSratMemoryAffinity *numamem; - MemoryAffinityFlags flags; - - for (cur =3D base, info =3D info_list; - cur < end; - cur +=3D size, info =3D info->next) { - numamem =3D acpi_data_push(table_data, sizeof *numamem); - - if (!info) { - /* - * Entry is required for Windows to enable memory hotplug in OS - * and for Linux to enable SWIOTLB when booted with less than - * 4G of RAM. Windows works better if the entry sets proximity - * to the highest NUMA node in the machine at the end of the - * reserved space. - * Memory devices may override proximity set by this entry, - * providing _PXM method if necessary. - */ - build_srat_memory(numamem, end - 1, 1, default_node, - MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENA= BLED); - break; - } - - mi =3D info->value; - is_nvdimm =3D (mi->type =3D=3D MEMORY_DEVICE_INFO_KIND_NVDIMM); - di =3D !is_nvdimm ? mi->u.dimm.data : mi->u.nvdimm.data; - - if (cur < di->addr) { - build_srat_memory(numamem, cur, di->addr - cur, default_node, - MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENA= BLED); - numamem =3D acpi_data_push(table_data, sizeof *numamem); - } - - size =3D di->size; - - flags =3D MEM_AFFINITY_ENABLED; - if (di->hotpluggable) { - flags |=3D MEM_AFFINITY_HOTPLUGGABLE; - } - if (is_nvdimm) { - flags |=3D MEM_AFFINITY_NON_VOLATILE; - } - - build_srat_memory(numamem, di->addr, size, di->node, flags); - } - - qapi_free_MemoryDeviceInfoList(info_list); -} - static void build_srat(GArray *table_data, BIOSLinker *linker, MachineState *machine) { @@ -2414,10 +2356,19 @@ build_srat(GArray *table_data, BIOSLinker *linker, = MachineState *machine) build_srat_memory(numamem, 0, 0, 0, MEM_AFFINITY_NOFLAGS); } =20 + /* + * Entry is required for Windows to enable memory hotplug in OS + * and for Linux to enable SWIOTLB when booted with less than + * 4G of RAM. Windows works better if the entry sets proximity + * to the highest NUMA node in the machine. + * Memory devices may override proximity set by this entry, + * providing _PXM method if necessary. + */ if (hotplugabble_address_space_size) { - build_srat_hotpluggable_memory(table_data, machine->device_memory-= >base, - hotplugabble_address_space_size, - pcms->numa_nodes - 1); + numamem =3D acpi_data_push(table_data, sizeof *numamem); + build_srat_memory(numamem, machine->device_memory->base, + hotplugabble_address_space_size, pcms->numa_node= s - 1, + MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENABLED= ); } =20 build_header(linker, table_data, --=20 MST