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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 187F3C468BD for ; Fri, 7 Jun 2019 17:34:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E87C520868 for ; Fri, 7 Jun 2019 17:34:52 +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="TiqYN4ZI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730033AbfFGRes (ORCPT ); Fri, 7 Jun 2019 13:34:48 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:46916 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729629AbfFGRes (ORCPT ); Fri, 7 Jun 2019 13:34:48 -0400 Received: by mail-oi1-f195.google.com with SMTP id 203so1962848oid.13 for ; Fri, 07 Jun 2019 10:34:48 -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=PQDn4Bg8QjtLfMA6U30U1R3x+u2Sc8pJdpkvrhwxItg=; b=TiqYN4ZIeJIcZdyH76CPw/HVLGladFFX1TaVyA8d+bt91TPBoOj+Wl/qYIgyST2If0 5Q53pA2tQdlIrIXAbCxchjf9ns3sci6CtmdDvUYrvO+YD3Ve5aaBvSMa9VMxmPhN4j3W Tn6nVuiG9Y78xQgJXKnl+5bg5ke1pBLB1GlQupAgv6HIX0F0U/aM7XPLV9VOXad4g4Lf LMgAgdHX6fzBlIhsSuKFqXCYO1qbZHMxYrPREEUVIDtZdlVAsMCCpwK3xKS/Lk71Awcd 0pVr2y0nBr1ueHaxoR1TDFfUyDNALDL/sX3kpjnRhqFMhc9LDiPs7+I3miDoeZpWxW9D 0NOg== 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=PQDn4Bg8QjtLfMA6U30U1R3x+u2Sc8pJdpkvrhwxItg=; b=qzUgvOcAC0pHnH39mwuOiCFdFzysKcwtUWAQ5BJr9UneYEypCQRWp7PwjBqdlhVbqU a+rdgLIPJrNZf7t9P5ZHJPbl/k9K0xf5MdLvKp2OdkcSljnok1MRV1LPcftAU6EoOFC8 d4XPSKsdRw1ZU3mUnohLQq/II85b3FUoBQNrqxuag6JS3AuKqfTQrbewxrx5Z79flIx8 nHEnOy2a8PirIQSclJtOQAVsAT1uAVMcRCOfTYSa+QJyLiQpiFEne8dnZeuyoTfxFRNv ZgVDWx+ZYVa8wD9a3IVrejtfLkb0rzo6mMcPwTcjU8/ClQQVjK99CyYOG3DrU5yT4R1p 1n/A== X-Gm-Message-State: APjAAAWJFZOylOpoPvngSvKyAsYIVYa+kqNJkN0I0SQATkaWj4kj59D2 6oXSDxf4iurTHExFXpn6DVY9TCUnbFkwWoAquCwKvA== X-Google-Smtp-Source: APXvYqwxRH9b7zfmNokXa/MJtvxICynfiQZqc9XkLddgj7G1h1cazph56bWLcewkRjUHU4E05igOxqptPTcARwRwv5E= X-Received: by 2002:aca:ec82:: with SMTP id k124mr1785826oih.73.1559928887822; Fri, 07 Jun 2019 10:34:47 -0700 (PDT) MIME-Version: 1.0 References: <155925716254.3775979.16716824941364738117.stgit@dwillia2-desk3.amr.corp.intel.com> <155925718351.3775979.13546720620952434175.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Fri, 7 Jun 2019 10:34:36 -0700 Message-ID: Subject: Re: [PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax To: Ard Biesheuvel Cc: Mike Rapoport , linux-efi , "the arch/x86 maintainers" , Borislav Petkov , Ingo Molnar , "H. Peter Anvin" , Darren Hart , Andy Shevchenko , Thomas Gleixner , kbuild test robot , Vishal L Verma , Linux-MM , Linux Kernel Mailing List , linux-nvdimm Content-Type: text/plain; charset="UTF-8" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Fri, Jun 7, 2019 at 8:23 AM Dan Williams wrote: > > On Fri, Jun 7, 2019 at 5:29 AM Ard Biesheuvel wrote: [..] > > > #ifdef CONFIG_EFI_APPLICATION_RESERVED > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md) > > > { > > > return md->type == EFI_CONVENTIONAL_MEMORY > > > && (md->attribute & EFI_MEMORY_SP); > > > } > > > #else > > > static inline bool is_efi_application_reserved(efi_memory_desc_t *md) > > > { > > > return false; > > > } > > > #endif > > > > I think this policy decision should not live inside the EFI subsystem. > > EFI just gives you the memory map, and mangling that information > > depending on whether you think a certain memory attribute should be > > ignored is the job of the MM subsystem. > > The problem is that we don't have an mm subsystem at the time a > decision needs to be made. The reservation policy needs to be deployed > before even memblock has been initialized in order to keep kernel > allocations out of the reservation. I agree with the sentiment I just > don't see how to practically achieve an optional "System RAM" vs > "Application Reserved" routing decision without an early (before > e820__memblock_setup()) conditional branch. I can at least move it out of include/linux/efi.h and move it to arch/x86/include/asm/efi.h since it is an x86 specific policy decision / implementation for now.