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 20EF4C4360C for ; Fri, 11 Oct 2019 02:39:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DCFE720B7C for ; Fri, 11 Oct 2019 02:39:50 +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="rD51Grqo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726371AbfJKCju (ORCPT ); Thu, 10 Oct 2019 22:39:50 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:33277 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726273AbfJKCju (ORCPT ); Thu, 10 Oct 2019 22:39:50 -0400 Received: by mail-ot1-f65.google.com with SMTP id 60so6722332otu.0 for ; Thu, 10 Oct 2019 19:39:49 -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=kUjGfToohnRw3RfgQ+9flaCfPAIrosIOz86XDKOCA7g=; b=rD51GrqogZjnKGZorLgmKzAIqApDPuKQyJfPxfapnklb83LBkH2gdg56h8iJjsNAxP Lp3Xdn8v+HFnoEdG86//8jnIHywJCYDtWHz4XjD66sYaVWFTFuG5xawBbDSfVMHwxqbL zJpwyYXv9QxOEG1VfWm0VW//lM5WUuwMSVNnvQqeD8bg3v3VUBZe5vmarhcKhkwl6D/G FzAomM5Ft+JWRlj+Qvjc/OTxDwkCzP8ZHRpDZfOZhRk7liObRTC6k1DZHjLkDgC58QIR TKQa9CiL9KrF3j/3Lp9Sz6NJ4ZwTauuCjO0J2Ga87+B7d/M9gJ6bqzK7Oybgfl/jji/O rrwg== 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=kUjGfToohnRw3RfgQ+9flaCfPAIrosIOz86XDKOCA7g=; b=qsKhtU39+OCM+gCAjgQxBz+p+5lQdgGiX6aOiF+ZOAHqd2EsB8Dtqn/o7+vBVYu3lt 5zIBjGdtoTuJHUi1kxKE4GtoQfdQZrxoHZI4HbrKyOHz60y1xPWOFXH748Z6nc+taNde vCIVTT1rbUk0/RJiStX5gd6XURPihbJVYPqPIPA0oMGRxQ/Rg3ccgjW+KZujh95/yHoD 0IKi97Ui2EsuGAh82TM4OUcLWCuznGG5vDHLPNXrtVn/oSmFvkaEK1rTT0RPV7RxQzpW 6Xnkc0r4Q22KPaw0gO8+Llafvc2FjVC1IasbYQeFjZfMIFwZoyc67uBEgB1zvwEZrNlf aASQ== X-Gm-Message-State: APjAAAVZaCaFckXDUenS2aPwaUA/fr+ChvwP9mqkHE/G7Ovj7WlMHKLf femdBE+FuhgszQS5xy9XT2O6EY9m3H39w3s2JS0z5A== X-Google-Smtp-Source: APXvYqyCjQsNSbI1mxag1lzJW/e/oU312qrBqdfJ38j8KxBq45vv+72ZX6iPup9KpaNI0dTRd5UK6J3tZdFLeJ9ljeo= X-Received: by 2002:a9d:7843:: with SMTP id c3mr8640549otm.71.1570761589216; Thu, 10 Oct 2019 19:39:49 -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 19:39:38 -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 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.