Message ID | 20240202163433.786581-3-abrestic@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp563922dyc; Fri, 2 Feb 2024 09:03:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IF8w/xFboRPuffKFL7lY/UEvZsuWdhGwnYcSmTx4BjrpXeRFwqpwrBCDlhiMQ9uNi67AFZQ X-Received: by 2002:a05:6870:b50c:b0:219:a4e:e6b0 with SMTP id v12-20020a056870b50c00b002190a4ee6b0mr325482oap.29.1706893393074; Fri, 02 Feb 2024 09:03:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706893393; cv=pass; d=google.com; s=arc-20160816; b=yddMFlJAfyMvAdhVoD2bdVDy1ZCh+UHhbrsfb3miMCYa9zXUbElj4sj+UBst6zATze DRCf8w5MI6E3FjlbO7w77F+5S5kVPSihYUsWpBNK6YHKiaXyAHEcoInsa5DGSCN2gFAY Aptva2cGtw4a1+3iRc3xh9lh/fTd6Ffv110bNA3rKha51q+FCx4bMWOdSc9IGgq3Ostg Pgrl15nE/39/qqbgrk0DqPYZNsCYHJmQNgeOJPdBinkXGEtrcoUOuzCpSMGpvRqv1REw FOiyNOtThmDPbPZU4UyQG4cVHSwNMPcjywkS8BTwhm6ZJUeIDKFCjbjlih3CTwCcxrJf jIQQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=Bqv6IbT5YBrkVHXBtAcPOljl6IyXNltBMTpBEU5EmMk=; fh=EAm3qcP+TV5ynBIfMMIUAOPE0bzjETG46Rr/n1juKrU=; b=Uz3qEqaNYD8odLPghz60/Egh4b8Qk5DSJN2fOLV2B23VCd/BMG9Y9PkMaMYkM64Cie CZQQYT/K0xtlghfE0cS0F8S4g93shvUd7XCanUfxzFvbtHSbJ8omzJegP2ysHy6xjVC8 fmcTG880nQXKp2ttyJ118r55FYXFFxE0sPAbF+JMEr9smU3vbQfQcy0mjQ0RYEhOwXMR nvPZKJW/mCPKmg6e8DZErPNul4vcLaV9i7ENlEzb31K11l7VVCQDg7w2VmMlk678zg2n 5WM2Vdbf4MJEbfElKso0S6w+W0dBANPMj6o1z3E06Yc6C2Wzt/xOOXQS98dHf6jbnYo5 jTcw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=qASvpXb5; arc=pass (i=1 spf=pass spfdomain=rivosinc.com dkim=pass dkdomain=rivosinc-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=1; AJvYcCV4CuGbNWd0fv2iJe7M3JoNRbPkdkYH7H8eRfN3BhK+LJ/qx0BN5ozweqxkJ2LFVKNPijrM/1dLIrrLK56+u6eLcCqA1Q== Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id 26-20020a63145a000000b005ce0a1164aesi1772499pgu.616.2024.02.02.09.03.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 09:03:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=qASvpXb5; arc=pass (i=1 spf=pass spfdomain=rivosinc.com dkim=pass dkdomain=rivosinc-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50148-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id CADC8B2315B for <ouuuleilei@gmail.com>; Fri, 2 Feb 2024 16:35:59 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E5DD514A0A3; Fri, 2 Feb 2024 16:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="qASvpXb5" Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE1D214900F for <linux-kernel@vger.kernel.org>; Fri, 2 Feb 2024 16:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706891692; cv=none; b=DOyBuuZCE333QpTm3KKjoZXRV8x0HUwA/qiUXzLu37BwDvuEpansM0CMWlEJxRXavREsb1UVJUFx37q1kXfd4SeXFv+RzT1jHCFjB3EFkm8UY3QzoqEgMpeek4D/zmQsjQ0bxRDdHkjFwHM1ImN4mbCQeD3GGSDfzW7UqAuK+jQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706891692; c=relaxed/simple; bh=6wzJzUOn25V37JzavypuqOKI2HSv2Q0C4HVDvOIYmqI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qJEbF10I86mirdwuIxaRM1w1T/zDBc146wEYz9jEL4gNcmvkv5hLo/LRUvNUT7PiJcJWyVoW2t7rjiMpKku29bp9oviuZ6S8qv6fhkgmmsGWL5AuTwJgGw/unHDRh/z1IApjLkKS6n1kdEL0t+rsZ4WHMkbfr2Y/aa3d3e1w5mU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=qASvpXb5; arc=none smtp.client-ip=209.85.215.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-5cfd95130c6so1543857a12.1 for <linux-kernel@vger.kernel.org>; Fri, 02 Feb 2024 08:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1706891690; x=1707496490; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Bqv6IbT5YBrkVHXBtAcPOljl6IyXNltBMTpBEU5EmMk=; b=qASvpXb5+QgDNx9N/WUpe1DkSlpp+G2g3zzxSJTjH4UIahWyvqFQmSaIaZuT9sUjfu 8sXbNmJpT6JQMEzl6haHnjCzsS92bKpMOyfCsVeJv/M1BodeHD4aGp4tWc8RaHmoOiFZ Pn+gL0R29J0R8Sj7SQjN7iVXAEK/A71DyMYCABfBamZQVtjanbtDyoLG8PN4F9o9bC21 vyjtrd+utvw2PmPGl3OF5DJlUg/Pfn9Fda4xYVzBOYp12bWGVQhg1LU+2zV6feoojHir y/65cKPNx5ggt2ems/5NA1Wl7smRnK7OjD8+VYXKig/HV506aUafNtgNcF9vZPMWGfup YSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706891690; x=1707496490; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Bqv6IbT5YBrkVHXBtAcPOljl6IyXNltBMTpBEU5EmMk=; b=ku+934T8JuwBTQnYP4shaO3AyhmOA2ryrLm2nbfhFsAR0KuV1UP1IQjukZHJKXaRkM eVnDY/cya3lqZijobkjxMO6b+piywpQt1qKvMg0YbPw2fyxlwaY0TNPQlt1oiQBuK7nV cb7jxZf69vyyZ4oUlYOJunKtRq7hKgoUnXuyepaqK1lk+6fCchS54tHAwG8Iw2pOXs3H x2d7mQw1XqtLcbuHFwCMTkUuZiYlebew658H1x5X/g8hoQmytXZOrFDHtZLyj0IrHWm3 cnaUwfZCZAuxkspJ7QwPMwAdxdBgbkp4JjhZ/7PGgGD6VyMddR2ohXr1rKTDfXLUCBtw vZsw== X-Gm-Message-State: AOJu0YzfUi0+aplwFyrt4kFvhsD2Vt6Y/pep9X2pCPodT1i3p1Waj6OL c0vy/MMMFfIfkmdfDl3vZPZW0H8F8ONZjow2YcimcnOh77tATly11OzDFfyiIQQ= X-Received: by 2002:a17:902:848b:b0:1d8:fcac:eff0 with SMTP id c11-20020a170902848b00b001d8fcaceff0mr7497653plo.9.1706891690057; Fri, 02 Feb 2024 08:34:50 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXMrpNV1ur1ZaUXyBREl/idQhnbrCLLbzfYUB6Yw5ZhB75G4Q5ZLpVuL60eFiSgHyQig+jkiOD/tHdIOzF+cK9nOkO9xQbFvFlf2pFBL/0ugpZBj5vBMrmBZNP44ch2ldgxCpOPavoC0ailhrqy3fOjDKBt9FTts48VbvXKCAdPTJ2pfBz1eKjn44ykacO+n6SixsVEAeA8I8Gcqw0pDXijksNLSVozgSD3J5gq9FQKAb4MDVqjy3mHagVLPo+ZjqteleNjFQnu52Zh Received: from abrestic.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id ju15-20020a170903428f00b001d75c26e857sm1784870plb.288.2024.02.02.08.34.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 08:34:49 -0800 (PST) From: Andrew Bresticker <abrestic@rivosinc.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Andrew Bresticker <abrestic@rivosinc.com> Subject: [PATCH 2/2] efi: Don't add memblocks for unusable memory Date: Fri, 2 Feb 2024 08:34:33 -0800 Message-Id: <20240202163433.786581-3-abrestic@rivosinc.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240202163433.786581-1-abrestic@rivosinc.com> References: <20240202163433.786581-1-abrestic@rivosinc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789806402538283288 X-GMAIL-MSGID: 1789807446769008280 |
Series |
efi: Fixes for EFI_MEMORY_SP memory on RISC-V and ARM64
|
|
Commit Message
Andrew Bresticker
Feb. 2, 2024, 4:34 p.m. UTC
Adding memblocks (even if nomap) for such regions unnecessarily consumes
resources by creating struct pages for memory that may never be used or,
in the case of soft-reserved regions, prevents the memory from later
being hotplugged in by dax_kmem. This is also consistent with how x86
handles unusable memory found in the EFI memory map.
Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
---
drivers/firmware/efi/efi-init.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
Comments
On Fri, Feb 2, 2024 at 11:45 AM Ard Biesheuvel <ardb@kernel.org> wrote: > > On Fri, 2 Feb 2024 at 17:34, Andrew Bresticker <abrestic@rivosinc.com> wrote: > > > > Adding memblocks (even if nomap) for such regions unnecessarily consumes > > resources by creating struct pages for memory that may never be used or, > > in the case of soft-reserved regions, prevents the memory from later > > being hotplugged in by dax_kmem. This is also consistent with how x86 > > handles unusable memory found in the EFI memory map. > > > > x86 doesn't care as much about memory vs device semantics as ARM does. > > This affects the output of memblock_is_[region_]memory(), so we'd have > to double check that none of those uses get broken by this. > > If the soft reserved regions need to be omitted from memblock, we can > deal with that separately perhaps, but changing it at this level seems > inappropriate to me. Sure, I can constrain this to just the soft-reserved regions. -Andrew > > > > Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> > > --- > > drivers/firmware/efi/efi-init.c | 12 +----------- > > 1 file changed, 1 insertion(+), 11 deletions(-) > > > > diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c > > index d4987d013080..f05bacac89b7 100644 > > --- a/drivers/firmware/efi/efi-init.c > > +++ b/drivers/firmware/efi/efi-init.c > > @@ -24,13 +24,6 @@ > > > > unsigned long __initdata screen_info_table = EFI_INVALID_TABLE_ADDR; > > > > -static int __init is_memory(efi_memory_desc_t *md) > > -{ > > - if (md->attribute & (EFI_MEMORY_WB|EFI_MEMORY_WT|EFI_MEMORY_WC)) > > - return 1; > > - return 0; > > -} > > - > > /* > > * Translate a EFI virtual address into a physical address: this is necessary, > > * as some data members of the EFI system table are virtually remapped after > > @@ -195,12 +188,9 @@ static __init void reserve_regions(void) > > memrange_efi_to_native(&paddr, &npages); > > size = npages << PAGE_SHIFT; > > > > - if (is_memory(md)) { > > + if (is_usable_memory(md)) { > > early_init_dt_add_memory_arch(paddr, size); > > > > - if (!is_usable_memory(md)) > > - memblock_mark_nomap(paddr, size); > > - > > /* keep ACPI reclaim memory intact for kexec etc. */ > > if (md->type == EFI_ACPI_RECLAIM_MEMORY) > > memblock_reserve(paddr, size); > > -- > > 2.34.1 > >
diff --git a/drivers/firmware/efi/efi-init.c b/drivers/firmware/efi/efi-init.c index d4987d013080..f05bacac89b7 100644 --- a/drivers/firmware/efi/efi-init.c +++ b/drivers/firmware/efi/efi-init.c @@ -24,13 +24,6 @@ unsigned long __initdata screen_info_table = EFI_INVALID_TABLE_ADDR; -static int __init is_memory(efi_memory_desc_t *md) -{ - if (md->attribute & (EFI_MEMORY_WB|EFI_MEMORY_WT|EFI_MEMORY_WC)) - return 1; - return 0; -} - /* * Translate a EFI virtual address into a physical address: this is necessary, * as some data members of the EFI system table are virtually remapped after @@ -195,12 +188,9 @@ static __init void reserve_regions(void) memrange_efi_to_native(&paddr, &npages); size = npages << PAGE_SHIFT; - if (is_memory(md)) { + if (is_usable_memory(md)) { early_init_dt_add_memory_arch(paddr, size); - if (!is_usable_memory(md)) - memblock_mark_nomap(paddr, size); - /* keep ACPI reclaim memory intact for kexec etc. */ if (md->type == EFI_ACPI_RECLAIM_MEMORY) memblock_reserve(paddr, size);