From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22084C10F14 for ; Thu, 10 Oct 2019 18:31:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE8432196E for ; Thu, 10 Oct 2019 18:31:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="ITKQdXgp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfJJSba (ORCPT ); Thu, 10 Oct 2019 14:31:30 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:46514 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726666AbfJJSba (ORCPT ); Thu, 10 Oct 2019 14:31:30 -0400 Received: by mail-oi1-f194.google.com with SMTP id k25so5758419oiw.13 for ; Thu, 10 Oct 2019 11:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NlpMtJuEn229jdoiy4a5lSiNwCR7W2uBuMkIb+tS29o=; b=ITKQdXgp39L1atnLKS6bIayQ9Oqf6ZZELR9iAOK+L6XNZQ850R0k4Wq+C591V98Nfl eOoLYUEr529lnsG7t+CJqDOS5QKMvY3XrF/SK6+tXNJNg9BD4lbBMGkxTzS4SKyjAfE0 xn569nIeqCMhNH4Y4rymaQEIHqH3V4m13e6nSsG5/FZXD9RZfFwMJB/hw6j/PKD3ZN/T djeRQXbH/RMf0D99jQQukYrMlxitWBZJXoV4zOuD12m3Dx19MOOY6ReMOh+CphTJycow Kw4sFaD4DJMEw5ZE07VFRdG2QdsYJ/yuG3REItWbHzEMRGeorpswB7PBjNsPdMSJLG68 yf0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NlpMtJuEn229jdoiy4a5lSiNwCR7W2uBuMkIb+tS29o=; b=ZpDjR/jQDDAd88O94Xc/i/mOktQF5KU8/m27rr96MrJhGTo3zQkU6ZtmPCZpkqkFSW ABxP9CPulDdEQeqDD2K1Fk6dA4gQOU3RAhbir/tzbafidgiPTcflJ01qYyR3IXMzPK0N t50oPXbuQ45s0+p84tjB5DCU4tnZ51Ek2qKNYD+hw+b0qlLW25HSLy+aUC/I+p7EHajr ap5MK08Bb9aIRgUcq+vi6cmwstKN/4+0l6iO5v4Lq34M2NgrNPE/pwaw4F7mQEDu/iJc o4rd9WVJgpCJJy42J77nnFhw157k9LWVLY5AGO+s7iAFOE8G7n8fMgKSQTZ2NX4qUjDH x1hQ== X-Gm-Message-State: APjAAAWcu3ypu3cPX6EZvMHSUrdMY7d8ORNZFOtxh1EpaCFJD8yoToJ1 ZbXNrl32l/iBnKMabqcolG2/rwfbSTSzqwaq5fKAvg== X-Google-Smtp-Source: APXvYqwfCh4W4PaSkjW/YpvNKY4Zzd3H20YtYmvM1Mygk9eFcMO2ybDevOXVp5f75aYzxtnTqkn5gtQosFy/farxU40= X-Received: by 2002:aca:620a:: with SMTP id w10mr9068177oib.0.1570732289023; Thu, 10 Oct 2019 11:31:29 -0700 (PDT) MIME-Version: 1.0 References: <157066227329.1059972.5659620631541203458.stgit@dwillia2-desk3.amr.corp.intel.com> <157066230358.1059972.1736585303527133478.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Thu, 10 Oct 2019 11:31:18 -0700 Message-ID: Subject: Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration To: Ard Biesheuvel Cc: Ingo Molnar , "the arch/x86 maintainers" , Borislav Petkov , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , kbuild test robot , Dave Hansen , Vishal L Verma , linux-efi , Linux Kernel Mailing List , ACPI Devel Maling List Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel wrote: > > On Thu, 10 Oct 2019 at 01:19, Dan Williams wrote: > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > interpretation of the EFI Memory Types as "reserved for a specific > > purpose". > > > > The proposed Linux behavior for specific purpose memory is that it is > > reserved for direct-access (device-dax) by default and not available for > > any kernel usage, not even as an OOM fallback. Later, through udev > > scripts or another init mechanism, these device-dax claimed ranges can > > be reconfigured and hot-added to the available System-RAM with a unique > > node identifier. This device-dax management scheme implements "soft" in > > the "soft reserved" designation by allowing some or all of the > > reservation to be recovered as typical memory. This policy can be > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with > > efi=nosoftreserve. > > > > This patch introduces 2 new concepts at once given the entanglement > > between early boot enumeration relative to memory that can optionally be > > reserved from the kernel page allocator by default. The new concepts > > are: > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP > > attribute on EFI_CONVENTIONAL memory, update the E820 map with this > > new type. Only perform this classification if the > > CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as > > typical ram. > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for > > a device driver to search iomem resources for application specific > > memory. Teach the iomem code to identify such ranges as "Soft Reserved". > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For > > now, just identify and reserve memory of this type. > > > > Cc: > > Cc: Borislav Petkov > > Cc: Ingo Molnar > > Cc: "H. Peter Anvin" > > Cc: Darren Hart > > Cc: Andy Shevchenko > > Cc: Andy Lutomirski > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Ard Biesheuvel > > Reported-by: kbuild test robot > > Reviewed-by: Dave Hansen > > Signed-off-by: Dan Williams > > For the EFI changes > > Acked-by: Ard Biesheuvel > > although I must admit I don't follow the enum add_efi_mode logic 100% I'm open to suggestions as I'm not sure it's the best possible organization. The do_add_efi_memmap() routine has the logic to translate EFI to E820, but unless "add_efi_memmap" is specified on the kernel command line the EFI memory map is ignored. For soft-reservation support I want to reuse do_add_efi_memmap(), but otherwise avoid any other side effects of considering the EFI map. What I'm missing is the rationale for why "add_efi_memmap" is required before considering the EFI memory map. If there is a negative side effect to always using the EFI map then the new "add_efi_mode" designation constrains it to just the soft-reservation case. It seems for historical reasons the full EFI memmap requires explicit opt-in: 200001eb140e x86 boot: only pick up additional EFI memmap if add_efi_memmap flag