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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 9309CECE58C for ; Fri, 11 Oct 2019 05:52:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 635C82196E for ; Fri, 11 Oct 2019 05:52:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="H62q2teO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727294AbfJKFwW (ORCPT ); Fri, 11 Oct 2019 01:52:22 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44135 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727265AbfJKFwU (ORCPT ); Fri, 11 Oct 2019 01:52:20 -0400 Received: by mail-wr1-f67.google.com with SMTP id z9so10374876wrl.11 for ; Thu, 10 Oct 2019 22:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SZfiDMytUZRJp44lJpGIhXKb56niFoQv8fJMmHQ6k+Q=; b=H62q2teOwJH5ebK+zs5CnU01YkWWT2VVaSnRzpi2uNOFHPYqzvw8c+8vmsqsn8mEAg d7JIoYPTS5haAA47mcEKlL6FBZSEcSQVPZ+NCEczpYto9FAcv2n7guL8eTYTTKrrd3VH gITCMTT4lshS5kOo3GfKuz03OO2sfIMmTNdcE2Tmy1+Ve6QnGkliu9IJ9nz01woccUz+ 4M87ZSxrzyTgUhYE//yN8vBlfwAsyrsAS+SO1EXwrDSrsaYtLVjXffkr/vsgIQfnrYpH z/UHWQS/OJKUc4bZP/BMzgLgHxmIFH2xzOcF7Hop9ZfUzmKZY5eQWVlkxsbG1AsVkrE5 b3lQ== 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=SZfiDMytUZRJp44lJpGIhXKb56niFoQv8fJMmHQ6k+Q=; b=GkVYjUTZcKqk+CMvofbjH4U8rSJx9DmLmIDzIG2gzbxA2Vgze1N8BGvN2QTHEt6AqO qT49QCeM66SoDpyEaexEiXw6gjflbC86fCEAmxf301l8akK5HwtqMkQMG3P+IXiKfdkS Lhmx9DwHs92nAc/8gJKIqpcK4AxrdFB2Uv1KEzjZVjlK6rFS3W8E5DAVvrpCg0jpQtZj aQy0QplwaYYa7AL0DYtJJ3Ody7Auual3OtF9uHuTV14aNFT3oFb7khE9VFwtjS4DQCpP XSkASlEdyalbSR6bdirg5Riup5qd5MeEjMpxoGzOYAVV8SXtVGt1dr+4+5+ycouMxTFw 9jPw== X-Gm-Message-State: APjAAAWfJt1qV6DiC+j2t2M/g6oPBR2B9uLdN68z84vK9wpYjeP2dkHz U5YVpZB4t4GgXIvbvCiT2kees5O5uGpxjdeIGeTHwg== X-Google-Smtp-Source: APXvYqxxiTj6vtkq39Hatr4ltQFAfwTxn9rdWjyu3eWv1M6qMg4Lklqb1C8QY9amZYuQKQWADLkS8EJvB1MJpjdGZik= X-Received: by 2002:adf:9f08:: with SMTP id l8mr10987816wrf.325.1570773138350; Thu, 10 Oct 2019 22:52:18 -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: Ard Biesheuvel Date: Fri, 11 Oct 2019 07:52:05 +0200 Message-ID: Subject: Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration To: Dan Williams 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Oct 2019 at 04:39, Dan Williams wrote: > > On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel > wrote: > > > > On Thu, 10 Oct 2019 at 20:31, Dan Williams wrote: > > > > > > 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. > > > > > > > Could we make the presence of any EFI_MEMORY_SP regions imply > > add_efi_memmap? That way, it is guaranteed that we don't regress > > existing systems, while establishing clear and unambiguous semantics > > for new systems that rely on these changes in order to be able to use > > the special purpose memory as intended. > > In fact that's how it works. EFI_MEMORY_SP is unconditionally added. > Other EFI memory types are optionally added with the add_efi_memmap > option. That is not what I meant. Why not behave as if 'add_efi_memmap' was passed if any EFI_MEMORY_SP regions exist?