From: Dan Williams <dan.j.williams@intel.com> To: linux-acpi@vger.kernel.org Cc: Jason Gunthorpe <jgg@ziepe.ca>, Peter Zijlstra <peterz@infradead.org>, Ard Biesheuvel <ardb@kernel.org>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Borislav Petkov <bp@alien8.de>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Brice Goglin <Brice.Goglin@inria.fr>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Andy Lutomirski <luto@kernel.org>, Tom Lendacky <thomas.lendacky@amd.com>, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/5] Manual definition of Soft Reserved memory devices Date: Mon, 02 Mar 2020 14:19:57 -0800 [thread overview] Message-ID: <158318759687.2216124.4684754859068906007.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) Given the current dearth of systems that supply an ACPI HMAT table, and the utility of being able to manually define device-dax "hmem" instances via the efi_fake_mem= option, relax the requirements for creating these devices. Specifically, add an option (numa=nohmat) to optionally disable consideration of the HMAT and update efi_fake_mem= to behave like memmap=nn!ss in terms of delimiting device boundaries. All review welcome of course, but the E820 changes want an x86 maintainer ack, the efi_fake_mem update needs Ard, and Rafael has previously shepherded the HMAT changes. For the changes to kernel/resource.c, where there is no clear maintainer, I just copied the last few people to make thoughtful changes in that area. I am happy to take these through the nvdimm tree along with these prerequisites already in -next: b2ca916ce392 ACPI: NUMA: Up-level "map to online node" functionality 4fcbe96e4d0b mm/numa: Skip NUMA_NO_NODE and online nodes in numa_map_to_online_node() 575e23b6e13c powerpc/papr_scm: Switch to numa_map_to_online_node() 1e5d8e1e47af x86/mm: Introduce CONFIG_NUMA_KEEP_MEMINFO 5d30f92e7631 x86/NUMA: Provide a range-to-target_node lookup facility 7b27a8622f80 libnvdimm/e820: Retrieve and populate correct 'target_node' info Tested with: numa=nohmat efi_fake_mem=4G@9G:0x40000,4G@13G:0x40000 ...to create to device-dax instances: # daxctl list -RDu [ { "path":"\/platform\/hmem.1", "id":1, "size":"4.00 GiB (4.29 GB)", "align":2097152, "devices":[ { "chardev":"dax1.0", "size":"4.00 GiB (4.29 GB)", "target_node":3, "mode":"devdax" } ] }, { "path":"\/platform\/hmem.0", "id":0, "size":"4.00 GiB (4.29 GB)", "align":2097152, "devices":[ { "chardev":"dax0.0", "size":"4.00 GiB (4.29 GB)", "target_node":2, "mode":"devdax" } ] } ] --- Dan Williams (5): ACPI: NUMA: Add 'nohmat' option efi/fake_mem: Arrange for a resource entry per efi_fake_mem instance ACPI: HMAT: Refactor hmat_register_target_device to hmem_register_device resource: Report parent to walk_iomem_res_desc() callback ACPI: HMAT: Attach a device for each soft-reserved range arch/x86/kernel/e820.c | 16 +++++- arch/x86/mm/numa.c | 4 + drivers/acpi/numa/hmat.c | 71 +++----------------------- drivers/dax/Kconfig | 5 ++ drivers/dax/Makefile | 3 - drivers/dax/hmem/Makefile | 6 ++ drivers/dax/hmem/device.c | 97 +++++++++++++++++++++++++++++++++++ drivers/dax/hmem/hmem.c | 2 - drivers/firmware/efi/x86_fake_mem.c | 12 +++- include/acpi/acpi_numa.h | 1 include/linux/dax.h | 8 +++ kernel/resource.c | 1 12 files changed, 156 insertions(+), 70 deletions(-) create mode 100644 drivers/dax/hmem/Makefile create mode 100644 drivers/dax/hmem/device.c rename drivers/dax/{hmem.c => hmem/hmem.c} (98%) base-commit: 7b27a8622f802761d5c6abd6c37b22312a35343c _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com> To: linux-acpi@vger.kernel.org Cc: Jason Gunthorpe <jgg@ziepe.ca>, Peter Zijlstra <peterz@infradead.org>, Ard Biesheuvel <ardb@kernel.org>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Borislav Petkov <bp@alien8.de>, Wei Yang <richardw.yang@linux.intel.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Brice Goglin <Brice.Goglin@inria.fr>, Thomas Gleixner <tglx@linutronix.de>, Jeff Moyer <jmoyer@redhat.com>, Ingo Molnar <mingo@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Andy Lutomirski <luto@kernel.org>, Tom Lendacky <thomas.lendacky@amd.com>, linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/5] Manual definition of Soft Reserved memory devices Date: Mon, 02 Mar 2020 14:19:57 -0800 [thread overview] Message-ID: <158318759687.2216124.4684754859068906007.stgit@dwillia2-desk3.amr.corp.intel.com> (raw) Given the current dearth of systems that supply an ACPI HMAT table, and the utility of being able to manually define device-dax "hmem" instances via the efi_fake_mem= option, relax the requirements for creating these devices. Specifically, add an option (numa=nohmat) to optionally disable consideration of the HMAT and update efi_fake_mem= to behave like memmap=nn!ss in terms of delimiting device boundaries. All review welcome of course, but the E820 changes want an x86 maintainer ack, the efi_fake_mem update needs Ard, and Rafael has previously shepherded the HMAT changes. For the changes to kernel/resource.c, where there is no clear maintainer, I just copied the last few people to make thoughtful changes in that area. I am happy to take these through the nvdimm tree along with these prerequisites already in -next: b2ca916ce392 ACPI: NUMA: Up-level "map to online node" functionality 4fcbe96e4d0b mm/numa: Skip NUMA_NO_NODE and online nodes in numa_map_to_online_node() 575e23b6e13c powerpc/papr_scm: Switch to numa_map_to_online_node() 1e5d8e1e47af x86/mm: Introduce CONFIG_NUMA_KEEP_MEMINFO 5d30f92e7631 x86/NUMA: Provide a range-to-target_node lookup facility 7b27a8622f80 libnvdimm/e820: Retrieve and populate correct 'target_node' info Tested with: numa=nohmat efi_fake_mem=4G@9G:0x40000,4G@13G:0x40000 ...to create to device-dax instances: # daxctl list -RDu [ { "path":"\/platform\/hmem.1", "id":1, "size":"4.00 GiB (4.29 GB)", "align":2097152, "devices":[ { "chardev":"dax1.0", "size":"4.00 GiB (4.29 GB)", "target_node":3, "mode":"devdax" } ] }, { "path":"\/platform\/hmem.0", "id":0, "size":"4.00 GiB (4.29 GB)", "align":2097152, "devices":[ { "chardev":"dax0.0", "size":"4.00 GiB (4.29 GB)", "target_node":2, "mode":"devdax" } ] } ] --- Dan Williams (5): ACPI: NUMA: Add 'nohmat' option efi/fake_mem: Arrange for a resource entry per efi_fake_mem instance ACPI: HMAT: Refactor hmat_register_target_device to hmem_register_device resource: Report parent to walk_iomem_res_desc() callback ACPI: HMAT: Attach a device for each soft-reserved range arch/x86/kernel/e820.c | 16 +++++- arch/x86/mm/numa.c | 4 + drivers/acpi/numa/hmat.c | 71 +++----------------------- drivers/dax/Kconfig | 5 ++ drivers/dax/Makefile | 3 - drivers/dax/hmem/Makefile | 6 ++ drivers/dax/hmem/device.c | 97 +++++++++++++++++++++++++++++++++++ drivers/dax/hmem/hmem.c | 2 - drivers/firmware/efi/x86_fake_mem.c | 12 +++- include/acpi/acpi_numa.h | 1 include/linux/dax.h | 8 +++ kernel/resource.c | 1 12 files changed, 156 insertions(+), 70 deletions(-) create mode 100644 drivers/dax/hmem/Makefile create mode 100644 drivers/dax/hmem/device.c rename drivers/dax/{hmem.c => hmem/hmem.c} (98%) base-commit: 7b27a8622f802761d5c6abd6c37b22312a35343c
next reply other threads:[~2020-03-02 22:36 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-02 22:19 Dan Williams [this message] 2020-03-02 22:19 ` [PATCH 0/5] Manual definition of Soft Reserved memory devices Dan Williams 2020-03-02 22:20 ` [PATCH 1/5] ACPI: NUMA: Add 'nohmat' option Dan Williams 2020-03-02 22:20 ` Dan Williams 2020-03-18 0:08 ` Dan Williams 2020-03-18 0:08 ` Dan Williams 2020-03-18 8:24 ` Rafael J. Wysocki 2020-03-18 8:24 ` Rafael J. Wysocki 2020-03-18 17:39 ` Dan Williams 2020-03-18 17:39 ` Dan Williams 2020-03-19 9:30 ` Rafael J. Wysocki 2020-03-19 9:30 ` Rafael J. Wysocki 2020-03-02 22:20 ` [PATCH 2/5] efi/fake_mem: Arrange for a resource entry per efi_fake_mem instance Dan Williams 2020-03-02 22:20 ` Dan Williams 2020-03-03 8:01 ` Ard Biesheuvel 2020-03-03 8:01 ` Ard Biesheuvel 2020-03-02 22:20 ` [PATCH 3/5] ACPI: HMAT: Refactor hmat_register_target_device to hmem_register_device Dan Williams 2020-03-02 22:20 ` Dan Williams 2020-03-02 22:20 ` [PATCH 4/5] resource: Report parent to walk_iomem_res_desc() callback Dan Williams 2020-03-02 22:20 ` Dan Williams 2020-03-05 14:42 ` Tom Lendacky 2020-03-05 14:42 ` Tom Lendacky 2020-03-17 22:04 ` Dan Williams 2020-03-17 22:04 ` Dan Williams 2020-03-02 22:20 ` [PATCH 5/5] ACPI: HMAT: Attach a device for each soft-reserved range Dan Williams 2020-03-02 22:20 ` Dan Williams 2020-03-10 23:38 ` kbuild test robot 2020-03-06 20:07 ` [PATCH 0/5] Manual definition of Soft Reserved memory devices Jeff Moyer 2020-03-06 20:07 ` Jeff Moyer 2020-03-06 21:05 ` Dan Williams 2020-03-06 21:05 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=158318759687.2216124.4684754859068906007.stgit@dwillia2-desk3.amr.corp.intel.com \ --to=dan.j.williams@intel.com \ --cc=Brice.Goglin@inria.fr \ --cc=Jonathan.Cameron@huawei.com \ --cc=ard.biesheuvel@linaro.org \ --cc=ardb@kernel.org \ --cc=bp@alien8.de \ --cc=dave.hansen@linux.intel.com \ --cc=hpa@zytor.com \ --cc=jgg@ziepe.ca \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=rjw@rjwysocki.net \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.