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 26E15ECE58C for ; Fri, 11 Oct 2019 14:42:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EC4B821E6F for ; Fri, 11 Oct 2019 14:42:23 +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="KjTfLZ9s" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727197AbfJKOmX (ORCPT ); Fri, 11 Oct 2019 10:42:23 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:37151 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbfJKOmW (ORCPT ); Fri, 11 Oct 2019 10:42:22 -0400 Received: by mail-ot1-f65.google.com with SMTP id k32so8164281otc.4 for ; Fri, 11 Oct 2019 07:42:21 -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=DTilIw9kuA9/ZhCVKjq7t0Q6xQINI3VdWiZdaAX92yU=; b=KjTfLZ9sbaX0HivZiN4cHJnsOpK3hFTGS5Y8ZzYKXwLkTQReEEf7cMwCEFQC5QY2xs 0x/rLue2CD9ODblikQU95h7c2+Oz+4QpD2iYBR0F87gvmOctZK4TghAsjbxxEALSeJAw QSRqYZT2bsJzFz666Wdsp+28CNHvmfteiNpMgNTHM2Q3uf+/DVBzn9BZIMLz+iU3VAWA 6bkCF5b+Y7OUMjrLQOIK6Xq8AG6zY6g6pIzy7fHojmIymTQFECpIk0yReHvLhzHih0F6 zB5E+R6W1FaMSvJ1bGepGXiDzg/FuLWHUQeFgBrjnBf0E1vX1S8ejyo7sDbilV+w0zcZ VI3w== 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=DTilIw9kuA9/ZhCVKjq7t0Q6xQINI3VdWiZdaAX92yU=; b=YF6viksB99l6oxLiMM7CI7uM8Lg9HqOyLhYCNbmDCNCVha+KfjfqAImCeiurEZV4Wl OBElqjCQ11Ly4T1UzX/khWuokvLx11jxc6Dhm/nem1a2WPDbykcxtY7rOSzeaLb0r4Bk dHPFMi9bMr7fyhNmEy44p4A9D8r41eu0rYdrIw+ZLtPEK44nnx8kz0OhrdWevCNZCaVG Uo9xhYlSTjyCioJFtLLR/W9os3+/xRTLriJiwJ1kG9a5SlQK6QukqLFR7+xa5BoiOheU GbHijDquuIYZ3t+o5ycuuI41YjaHUBmnihDsjTrl00wgPTd4bSrQwtiq4wQbKbvr3HCy DBkQ== X-Gm-Message-State: APjAAAUBYV93WwE2LWQHESuEWbwwrFKjrkLIdwh7sntWyG1N5dalkmxO 2b1ptNU18LVxWsfJ1dMz7XtJhkB9AUnRL7/8Ujbl3Q== X-Google-Smtp-Source: APXvYqwbudi4rN4fTGWZokyloO/sdPo8umpYpvPsXhd6DJ//G8XqDY9mywrjwmYrdj4F50rvy8xzyKsE7vc8ZY7tDOQ= X-Received: by 2002:a9d:3ee:: with SMTP id f101mr12615074otf.126.1570804528988; Fri, 11 Oct 2019 07:35:28 -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: Fri, 11 Oct 2019 07:35: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 Thu, Oct 10, 2019 at 10:52 PM Ard Biesheuvel wrote: > > 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? Hmm, ok, on the assumption that any platform that is modern enough to specify EFI_MEMORY_SP likely does not need the opt-in? I can get on board with that. It's also simple enough to undo if it causes problems in practice.