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=-6.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS 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 24918C54FD0 for ; Tue, 24 Mar 2020 21:07:06 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EBC5620870 for ; Tue, 24 Mar 2020 21:07:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="ptpy7rs5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBC5620870 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id F2D5A10FC359C; Tue, 24 Mar 2020 14:07:55 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::241; helo=mail-oi1-x241.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 98F541007B8F8 for ; Tue, 24 Mar 2020 14:07:54 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id k18so58121oib.3 for ; Tue, 24 Mar 2020 14:07:04 -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=upl2vPR8qJWq0P3veNASLF2x9fKiteylDIqdLD2DSM4=; b=ptpy7rs5mB6uI4afsGX5d/xHC6v7jmwoP62AcU7hxqL8oy2KD1VBx8vnzGN1Z/YTu9 eQ2RSUwJ8nwlwFEdQaeBQML+Iairvcj1+qqNWJRo8jkY6k8tyFkYrc6Y/cP8aez8cl6K hwoPHaoibOwKdsohj+wZ+OwahZk2LbNJbzWMs9Ydj33jMr+HkVS/L5JZWugDUnywZrBP KTt9kpWf6BW8M03A4JP8SwzRz5ntebA8IUbxg+tqsU6koNGEeAi3UMY/3t7BT2/9+2EC MxHJuiEganu/DEyTeou3e77JmKbYjRNYEMiesXx+7UTQk6Li+EpZgi/Qw+zSXEQRCbVl hoHA== 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=upl2vPR8qJWq0P3veNASLF2x9fKiteylDIqdLD2DSM4=; b=rURvFCnTPJQLCBrUXUTt4ZhaVtT0YA23rq3MRtMgKfU0kUFHCzCp1d8xu7OWTydALU QaujmwkFi1V7xpP7b1tVQ0hghJwhvYqjLhRwDV4SfIv33Ik/sWOzkrbCRkpPW3a2jL9n 0qWW3y3YU/sj71IpRkpyw2AAXKspLY/fu2zotKHTefUH3PrS7Tke6ma3eLx287lX/cNk 9iYwx/w8blRxVukiRIp5WE35Um0RxbCwXwrzCmaBvDFos6jAvKv5gTLHmzk2ADNqgy+c 0ap2wQ/MqWBL29X/Jb7KlsaoF9VrhVvduQat+Cg5BzJaG9L5+fL4ybiBtZiithlf7Q/B 4cSQ== X-Gm-Message-State: ANhLgQ1vP+/t6FOlWLnO1OtKGCGH3yAezhfTk64QX1jg0PbHZ4fvbBUI F2VSsHqcGTLDQa3XlndKNoOU9FXZHukp+I08H3NKpw== X-Google-Smtp-Source: ADFU+vuuDTsX06lZ5QDww1C30E0693xGC6g3aELOAtPsdQe2suA+4qwGyRU1gvFT4j93s/mxQFsdDqEm0rp7qk9yuRQ= X-Received: by 2002:a05:6808:b0f:: with SMTP id s15mr151586oij.105.1585084023289; Tue, 24 Mar 2020 14:07:03 -0700 (PDT) MIME-Version: 1.0 References: <158489354353.1457606.8327903161927980740.stgit@dwillia2-desk3.amr.corp.intel.com> <158489357825.1457606.17352509511987748598.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Tue, 24 Mar 2020 14:06:52 -0700 Message-ID: Subject: Re: [PATCH v2 6/6] ACPI: HMAT: Attach a device for each soft-reserved range To: Joao Martins Message-ID-Hash: S6PEIP7DC7XZXNL5ZIUZCEGSIR72QEIO X-Message-ID-Hash: S6PEIP7DC7XZXNL5ZIUZCEGSIR72QEIO X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Linux ACPI , Jonathan Cameron , Brice Goglin , Ard Biesheuvel , "Rafael J. Wysocki" , Catalin Marinas , Will Deacon , Peter Zijlstra , Dave Hansen , linux-nvdimm , Linux Kernel Mailing List , X86 ML X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Mar 24, 2020 at 12:41 PM Joao Martins wrote: > > On 3/22/20 4:12 PM, Dan Williams wrote: > > The hmem enabling in commit 'cf8741ac57ed ("ACPI: NUMA: HMAT: Register > > "soft reserved" memory as an "hmem" device")' only registered ranges to > > the hmem driver for each soft-reservation that also appeared in the > > HMAT. While this is meant to encourage platform firmware to "do the > > right thing" and publish an HMAT, the corollary is that platforms that > > fail to publish an accurate HMAT will strand memory from Linux usage. > > Additionally, the "efi_fake_mem" kernel command line option enabling > > will strand memory by default without an HMAT. > > > > Arrange for "soft reserved" memory that goes unclaimed by HMAT entries > > to be published as raw resource ranges for the hmem driver to consume. > > > > Include a module parameter to disable either this fallback behavior, or > > the hmat enabling from creating hmem devices. The module parameter > > requires the hmem device enabling to have unique name in the module > > namespace: "device_hmem". > > > > Rather than mark this x86-only, include an interim phys_to_target_node() > > implementation for arm64. > > > > Cc: Jonathan Cameron > > Cc: Brice Goglin > > Cc: Ard Biesheuvel > > Cc: "Rafael J. Wysocki" > > Cc: Jeff Moyer > > Cc: Catalin Marinas > > Cc: Will Deacon > > Signed-off-by: Dan Williams > > --- > > arch/arm64/mm/numa.c | 13 +++++++++++++ > > drivers/dax/Kconfig | 1 + > > drivers/dax/hmem/Makefile | 3 ++- > > drivers/dax/hmem/device.c | 33 +++++++++++++++++++++++++++++++++ > > 4 files changed, 49 insertions(+), 1 deletion(-) > > > > [...] > > > diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c > > index 99bc15a8b031..f9c5fa8b1880 100644 > > --- a/drivers/dax/hmem/device.c > > +++ b/drivers/dax/hmem/device.c > > @@ -4,6 +4,9 @@ > > #include > > #include > > > > +static bool nohmem; > > +module_param_named(disable, nohmem, bool, 0444); > > + > > void hmem_register_device(int target_nid, struct resource *r) > > { > > /* define a clean / non-busy resource for the platform device */ > > @@ -16,6 +19,9 @@ void hmem_register_device(int target_nid, struct resource *r) > > struct memregion_info info; > > int rc, id; > > > > + if (nohmem) > > + return; > > + > > rc = region_intersects(res.start, resource_size(&res), IORESOURCE_MEM, > > IORES_DESC_SOFT_RESERVED); > > if (rc != REGION_INTERSECTS) > > @@ -62,3 +68,30 @@ void hmem_register_device(int target_nid, struct resource *r) > > out_pdev: > > memregion_free(id); > > } > > + > > +static __init int hmem_register_one(struct resource *res, void *data) > > +{ > > + /* > > + * If the resource is not a top-level resource it was already > > + * assigned to a device by the HMAT parsing. > > + */ > > + if (res->parent != &iomem_resource) > > + return 0; > > + > > + hmem_register_device(phys_to_target_node(res->start), res); > > + > > + return 0; > > Should we add an error returning value to hmem_register_device() perhaps this > ought to be reflected in hmem_register_one(). > > > +} > > + > > +static __init int hmem_init(void) > > +{ > > + walk_iomem_res_desc(IORES_DESC_SOFT_RESERVED, > > + IORESOURCE_MEM, 0, -1, NULL, hmem_register_one); > > + return 0; > > +} > > + > > (...) and then perhaps here returning in the initcall if any of the resources > failed hmem registration? Except that hmem_register_one() is a stop-gap to collect soft-reserved ranges that were not already registered, and it's not an error to find already registered devices. However, I do think it's a good idea to log registrations that failed for other reasons. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 67269C54FCF for ; Tue, 24 Mar 2020 21:07:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C3A12074D for ; Tue, 24 Mar 2020 21:07:05 +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="ptpy7rs5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727496AbgCXVHE (ORCPT ); Tue, 24 Mar 2020 17:07:04 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:40040 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727270AbgCXVHE (ORCPT ); Tue, 24 Mar 2020 17:07:04 -0400 Received: by mail-oi1-f196.google.com with SMTP id y71so34759oia.7 for ; Tue, 24 Mar 2020 14:07:03 -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=upl2vPR8qJWq0P3veNASLF2x9fKiteylDIqdLD2DSM4=; b=ptpy7rs5mB6uI4afsGX5d/xHC6v7jmwoP62AcU7hxqL8oy2KD1VBx8vnzGN1Z/YTu9 eQ2RSUwJ8nwlwFEdQaeBQML+Iairvcj1+qqNWJRo8jkY6k8tyFkYrc6Y/cP8aez8cl6K hwoPHaoibOwKdsohj+wZ+OwahZk2LbNJbzWMs9Ydj33jMr+HkVS/L5JZWugDUnywZrBP KTt9kpWf6BW8M03A4JP8SwzRz5ntebA8IUbxg+tqsU6koNGEeAi3UMY/3t7BT2/9+2EC MxHJuiEganu/DEyTeou3e77JmKbYjRNYEMiesXx+7UTQk6Li+EpZgi/Qw+zSXEQRCbVl hoHA== 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=upl2vPR8qJWq0P3veNASLF2x9fKiteylDIqdLD2DSM4=; b=YNM8yH5Cf8f6IhFM0kXi1bZomQ2I5ECPGuxeTb3N+jDJwFyHQlSamvVeJrRGuP2z3X 5dy5pF1Jwe9ACEoPZhRieH2GbBazs+pLdAQEAeXJdHRjkZ7pmFEwbXon4OJ6+M+2Q0CO 5KmrSel0jaAP269nfjQ/xwzbRgu4ebJ9cj9mkEnxUgqM/UHPJMRhhmMLGKChwnU2OYRu YM1qFtU3S/TtCqAWdTJvdXZsc2TvVeSXHonjZ4iy2ZDJ5rGuOKUEqytqUqkeCKC+UYAK 0+xJIdr+c9oz/gX8xCjMQJzndjohqEnMXP/+m5t1Q/dh8+Shtv3Q5NUNZXu1YwpIeoLQ /uFw== X-Gm-Message-State: ANhLgQ1St9i0qGhnRavVWQ9Al7Zw7w/HHNrGWxDttlXyxUn4PuuwJ7az g2QXJa2MX72oNmEPwbs6MjpTIlb4c8Yh768aymZPZA== X-Google-Smtp-Source: ADFU+vuuDTsX06lZ5QDww1C30E0693xGC6g3aELOAtPsdQe2suA+4qwGyRU1gvFT4j93s/mxQFsdDqEm0rp7qk9yuRQ= X-Received: by 2002:a05:6808:b0f:: with SMTP id s15mr151586oij.105.1585084023289; Tue, 24 Mar 2020 14:07:03 -0700 (PDT) MIME-Version: 1.0 References: <158489354353.1457606.8327903161927980740.stgit@dwillia2-desk3.amr.corp.intel.com> <158489357825.1457606.17352509511987748598.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Dan Williams Date: Tue, 24 Mar 2020 14:06:52 -0700 Message-ID: Subject: Re: [PATCH v2 6/6] ACPI: HMAT: Attach a device for each soft-reserved range To: Joao Martins Cc: Linux ACPI , Jonathan Cameron , Brice Goglin , Ard Biesheuvel , "Rafael J. Wysocki" , Catalin Marinas , Will Deacon , Peter Zijlstra , Dave Hansen , linux-nvdimm , Linux Kernel Mailing List , X86 ML 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 Tue, Mar 24, 2020 at 12:41 PM Joao Martins wrote: > > On 3/22/20 4:12 PM, Dan Williams wrote: > > The hmem enabling in commit 'cf8741ac57ed ("ACPI: NUMA: HMAT: Register > > "soft reserved" memory as an "hmem" device")' only registered ranges to > > the hmem driver for each soft-reservation that also appeared in the > > HMAT. While this is meant to encourage platform firmware to "do the > > right thing" and publish an HMAT, the corollary is that platforms that > > fail to publish an accurate HMAT will strand memory from Linux usage. > > Additionally, the "efi_fake_mem" kernel command line option enabling > > will strand memory by default without an HMAT. > > > > Arrange for "soft reserved" memory that goes unclaimed by HMAT entries > > to be published as raw resource ranges for the hmem driver to consume. > > > > Include a module parameter to disable either this fallback behavior, or > > the hmat enabling from creating hmem devices. The module parameter > > requires the hmem device enabling to have unique name in the module > > namespace: "device_hmem". > > > > Rather than mark this x86-only, include an interim phys_to_target_node() > > implementation for arm64. > > > > Cc: Jonathan Cameron > > Cc: Brice Goglin > > Cc: Ard Biesheuvel > > Cc: "Rafael J. Wysocki" > > Cc: Jeff Moyer > > Cc: Catalin Marinas > > Cc: Will Deacon > > Signed-off-by: Dan Williams > > --- > > arch/arm64/mm/numa.c | 13 +++++++++++++ > > drivers/dax/Kconfig | 1 + > > drivers/dax/hmem/Makefile | 3 ++- > > drivers/dax/hmem/device.c | 33 +++++++++++++++++++++++++++++++++ > > 4 files changed, 49 insertions(+), 1 deletion(-) > > > > [...] > > > diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c > > index 99bc15a8b031..f9c5fa8b1880 100644 > > --- a/drivers/dax/hmem/device.c > > +++ b/drivers/dax/hmem/device.c > > @@ -4,6 +4,9 @@ > > #include > > #include > > > > +static bool nohmem; > > +module_param_named(disable, nohmem, bool, 0444); > > + > > void hmem_register_device(int target_nid, struct resource *r) > > { > > /* define a clean / non-busy resource for the platform device */ > > @@ -16,6 +19,9 @@ void hmem_register_device(int target_nid, struct resource *r) > > struct memregion_info info; > > int rc, id; > > > > + if (nohmem) > > + return; > > + > > rc = region_intersects(res.start, resource_size(&res), IORESOURCE_MEM, > > IORES_DESC_SOFT_RESERVED); > > if (rc != REGION_INTERSECTS) > > @@ -62,3 +68,30 @@ void hmem_register_device(int target_nid, struct resource *r) > > out_pdev: > > memregion_free(id); > > } > > + > > +static __init int hmem_register_one(struct resource *res, void *data) > > +{ > > + /* > > + * If the resource is not a top-level resource it was already > > + * assigned to a device by the HMAT parsing. > > + */ > > + if (res->parent != &iomem_resource) > > + return 0; > > + > > + hmem_register_device(phys_to_target_node(res->start), res); > > + > > + return 0; > > Should we add an error returning value to hmem_register_device() perhaps this > ought to be reflected in hmem_register_one(). > > > +} > > + > > +static __init int hmem_init(void) > > +{ > > + walk_iomem_res_desc(IORES_DESC_SOFT_RESERVED, > > + IORESOURCE_MEM, 0, -1, NULL, hmem_register_one); > > + return 0; > > +} > > + > > (...) and then perhaps here returning in the initcall if any of the resources > failed hmem registration? Except that hmem_register_one() is a stop-gap to collect soft-reserved ranges that were not already registered, and it's not an error to find already registered devices. However, I do think it's a good idea to log registrations that failed for other reasons.