Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3941839pxj; Mon, 21 Jun 2021 09:51:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjlvDNS6uDtfp2vS7W576DX8hg9BxDvXRLQdRRcTLnwi6iUVxohaGW6gRlHDgU4Sl77Iah X-Received: by 2002:a05:6e02:1a4c:: with SMTP id u12mr7615098ilv.176.1624294293784; Mon, 21 Jun 2021 09:51:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624294293; cv=none; d=google.com; s=arc-20160816; b=u3wuReGsCAL/MJMwZYHVJzdWvGn+x78+kDhtaCVwWzF78yiP3tqu/HwJfCcE3qs1nU K//QXK/6qvzPS/JML9dLTfNGrTdM88N2WRYTigPBsoJhfmiO5GOr/xkWHCBPHb16ZAQu lQ/LcwjPvw3Zcu5bw7wO89jsfgNYQt084EK4rl/DdO9qstDWsVUujeSNkqexw5A75S04 rilPd1buQQAALRHZE9Oo5LN6BUeTnnDg8gYiW1T2qE7kR6s5UZGrxgALOTsQFhPxRIyy ibpxO33YBKFM87EAvpkEhzTyVONLXaHME42ZEUTKbX2WIsv1/p10Eh9bUlR7ubqEZD71 l2bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=g7M7KUdAuD9kriRm8XxDtwD6vHeZtLMJ094MDU5sZww=; b=jsa/55HhZyDgHrvR6RA187YOs1iq2ruoYqqYugPknit6KHZBlO+llQ0TJ/bMYgCPxp KkmutmPgSgCZQXs8NJe1Ak/8M+MN1lQoRvg84it4Q0Szo/cfK6ZV66A8mwKNL0udTfqO HbBa0bHzeUw9AYCQEdJdJuRZvN8MwbLJ1KHJfWhmeoTfc1ZX0p0nPhD5MWo1XWo4kZEx ZgpihnDMdpqYuEdAqEWljAR0Thi863WjCHx9gqKs1Yc6lqjayxhFSVjwsiJvD7JCkrrC Ir8UuXcHtcb3Oxk3ILr8HjPmqga6uiLq1HB395XW1aw3Zs0Uv44ffKakQVlwMzF13F7s 3CbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RyE1PR+A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si4854571ioq.12.2021.06.21.09.51.21; Mon, 21 Jun 2021 09:51:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RyE1PR+A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233258AbhFUQwf (ORCPT + 99 others); Mon, 21 Jun 2021 12:52:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:38048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232424AbhFUQrh (ORCPT ); Mon, 21 Jun 2021 12:47:37 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4B560613F6; Mon, 21 Jun 2021 16:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1624293211; bh=mzFB7BJnOi3qQUbcanvJmanEMO/M7hOK+kOcLMJVZUo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RyE1PR+AwbZJskbNjTjICTZid58VkDnXLd1wyGhpreB+QBikyzZy0K6PojYuG9Tk5 q8Vgb9TDaeyt/miz6gVQWjcp6EmTnjYmkrKhOsXUKkkz0Zgmx7zwTi1g1FQjjfJ3YG Fs/99xecdresh8G/INWTAVqI/5r8BHPPfOJ0WtQY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Reinette Chatre , Fan Du , Dave Hansen , Borislav Petkov , Jarkko Sakkinen , Dan Williams Subject: [PATCH 5.12 140/178] x86/mm: Avoid truncating memblocks for SGX memory Date: Mon, 21 Jun 2021 18:15:54 +0200 Message-Id: <20210621154927.539481178@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210621154921.212599475@linuxfoundation.org> References: <20210621154921.212599475@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Fan Du commit 28e5e44aa3f4e0e0370864ed008fb5e2d85f4dc8 upstream. tl;dr: Several SGX users reported seeing the following message on NUMA systems: sgx: [Firmware Bug]: Unable to map EPC section to online node. Fallback to the NUMA node 0. This turned out to be the memblock code mistakenly throwing away SGX memory. === Full Changelog === The 'max_pfn' variable represents the highest known RAM address. It can be used, for instance, to quickly determine for which physical addresses there is mem_map[] space allocated. The numa_meminfo code makes an effort to throw out ("trim") all memory blocks which are above 'max_pfn'. SGX memory is not considered RAM (it is marked as "Reserved" in the e820) and is not taken into account by max_pfn. Despite this, SGX memory areas have NUMA affinity and are enumerated in the ACPI SRAT table. The existing SGX code uses the numa_meminfo mechanism to look up the NUMA affinity for its memory areas. In cases where SGX memory was above max_pfn (usually just the one EPC section in the last highest NUMA node), the numa_memblock is truncated at 'max_pfn', which is below the SGX memory. When the SGX code tries to look up the affinity of this memory, it fails and produces an error message: sgx: [Firmware Bug]: Unable to map EPC section to online node. Fallback to the NUMA node 0. and assigns the memory to NUMA node 0. Instead of silently truncating the memory block at 'max_pfn' and dropping the SGX memory, add the truncated portion to 'numa_reserved_meminfo'. This allows the SGX code to later determine the NUMA affinity of its 'Reserved' area. Before, numa_meminfo looked like this (from 'crash'): blk = { start = 0x0, end = 0x2080000000, nid = 0x0 } { start = 0x2080000000, end = 0x4000000000, nid = 0x1 } numa_reserved_meminfo is empty. With this, numa_meminfo looks like this: blk = { start = 0x0, end = 0x2080000000, nid = 0x0 } { start = 0x2080000000, end = 0x4000000000, nid = 0x1 } and numa_reserved_meminfo has an entry for node 1's SGX memory: blk = { start = 0x4000000000, end = 0x4080000000, nid = 0x1 } [ daveh: completely rewrote/reworked changelog ] Fixes: 5d30f92e7631 ("x86/NUMA: Provide a range-to-target_node lookup facility") Reported-by: Reinette Chatre Signed-off-by: Fan Du Signed-off-by: Dave Hansen Signed-off-by: Borislav Petkov Reviewed-by: Jarkko Sakkinen Reviewed-by: Dan Williams Reviewed-by: Dave Hansen Cc: Link: https://lkml.kernel.org/r/20210617194657.0A99CB22@viggo.jf.intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/mm/numa.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -254,7 +254,13 @@ int __init numa_cleanup_meminfo(struct n /* make sure all non-reserved blocks are inside the limits */ bi->start = max(bi->start, low); - bi->end = min(bi->end, high); + + /* preserve info for non-RAM areas above 'max_pfn': */ + if (bi->end > high) { + numa_add_memblk_to(bi->nid, high, bi->end, + &numa_reserved_meminfo); + bi->end = high; + } /* and there's no empty block */ if (bi->start >= bi->end)