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=BAYES_00,DKIMWL_WL_HIGH, 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 BAECCC433E1 for ; Fri, 21 Aug 2020 23:22:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 75B7B207DF for ; Fri, 21 Aug 2020 23:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598052164; bh=r4O1OidhCLTtA4EIWBPUeXM2yn81FxJXDb6e1e2eG8o=; h=Date:From:To:Subject:Reply-To:List-ID:From; b=IJOuYQ+25Eg8epV2OaDaj62U2AkxEoJTfiMpZSoZc96RwzqsgISSWZwMoVesIG/TG 0RnmiZ5DpI4nr4TKDl/h/4jR6wDESbBfdmj9pY2hJt91QQyXcJpk5W99JHDPD0s07y AGBcR8fJFknULsPw+hhqHM51qxpiPoTm+qB1eFf4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726727AbgHUXWo (ORCPT ); Fri, 21 Aug 2020 19:22:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:55888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726541AbgHUXWl (ORCPT ); Fri, 21 Aug 2020 19:22:41 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9E501207C3; Fri, 21 Aug 2020 23:22:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598052160; bh=r4O1OidhCLTtA4EIWBPUeXM2yn81FxJXDb6e1e2eG8o=; h=Date:From:To:Subject:From; b=wWINj3k/n5nhHI165CHWwMhrBuVjYPDccw4HXduIe6TtYzFzPNg3GR5pRUz1Jbxtt PRtY4ntr5dHOy1BbYjGvN73+SUwqz9hBOrfZUZEMi7GHuow/SPz+syJ+rTCZIuLBxh IYgdtyOjlG4AHFUiN+hQbbxKvc5mxsKS06tB20TI= Date: Fri, 21 Aug 2020 16:22:38 -0700 From: akpm@linux-foundation.org To: airlied@linux.ie, ard.biesheuvel@linaro.org, ardb@kernel.org, benh@kernel.crashing.org, bp@alien8.de, Brice.Goglin@inria.fr, bskeggs@redhat.com, catalin.marinas@arm.com, dan.j.williams@intel.com, daniel@ffwll.ch, dave.hansen@linux.intel.com, dave.jiang@intel.com, david@redhat.com, gregkh@linuxfoundation.org, hpa@zytor.com, ira.weiny@intel.com, jgg@mellanox.com, jmoyer@redhat.com, joao.m.martins@oracle.com, Jonathan.Cameron@huawei.com, justin.he@arm.com, luto@kernel.org, mingo@redhat.com, mm-commits@vger.kernel.org, mpe@ellerman.id.au, pasha.tatashin@soleen.com, paulus@ozlabs.org, peterz@infradead.org, rafael.j.wysocki@intel.com, rafael@kernel.org, richardw.yang@linux.intel.com, rjw@rjwysocki.net, rppt@linux.ibm.com, tglx@linutronix.de, thomas.lendacky@amd.com, vishal.l.verma@intel.com, will@kernel.org Subject: + x86-numa-cleanup-configuration-dependent-command-line-options.patch added to -mm tree Message-ID: <20200821232238.fW8c2DRfz%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: mm-commits-owner@vger.kernel.org Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: x86/numa: cleanup configuration dependent command-line options has been added to the -mm tree. Its filename is x86-numa-cleanup-configuration-dependent-command-line-options.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/x86-numa-cleanup-configuration-dependent-command-line-options.patch and later at https://ozlabs.org/~akpm/mmotm/broken-out/x86-numa-cleanup-configuration-dependent-command-line-options.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Dan Williams Subject: x86/numa: cleanup configuration dependent command-line options Patch series "device-dax: Support sub-dividing soft-reserved ranges", v4. The device-dax facility allows an address range to be directly mapped through a chardev, or optionally hotplugged to the core kernel page allocator as System-RAM. It is the mechanism for converting persistent memory (pmem) to be used as another volatile memory pool i.e. the current Memory Tiering hot topic on linux-mm. In the case of pmem the nvdimm-namespace-label mechanism can sub-divide it, but that labeling mechanism is not available / applicable to soft-reserved ("EFI specific purpose") memory [3]. This series provides a sysfs-mechanism for the daxctl utility to enable provisioning of volatile-soft-reserved memory ranges. The motivations for this facility are: 1/ Allow performance differentiated memory ranges to be split between kernel-managed and directly-accessed use cases. 2/ Allow physical memory to be provisioned along performance relevant address boundaries. For example, divide a memory-side cache [4] along cache-color boundaries. 3/ Parcel out soft-reserved memory to VMs using device-dax as a security / permissions boundary [5]. Specifically I have seen people (ab)using memmap=nn!ss (mark System-RAM as Persistent Memory) just to get the device-dax interface on custom address ranges. A follow-on for the VM use case is to teach device-dax to dynamically allocate 'struct page' at runtime to reduce the duplication of 'struct page' space in both the guest and the host kernel for the same physical pages. [2]: http://lore.kernel.org/r/20200713160837.13774-11-joao.m.martins@oracle.com [3]: http://lore.kernel.org/r/157309097008.1579826.12818463304589384434.stgit@dwillia2-desk3.amr.corp.intel.com [4]: http://lore.kernel.org/r/154899811738.3165233.12325692939590944259.stgit@dwillia2-desk3.amr.corp.intel.com [5]: http://lore.kernel.org/r/20200110190313.17144-1-joao.m.martins@oracle.com This patch (of 23): In preparation for adding a new numa= option clean up the existing ones to avoid ifdefs in numa_setup(), and provide feedback when the option is numa=fake= option is invalid due to kernel config. The same does not need to be done for numa=noacpi, since the capability is already hard disabled at compile-time. Link: https://lkml.kernel.org/r/159643094279.4062302.17779410714418721328.stgit@dwillia2-desk3.amr.corp.intel.com Link: https://lkml.kernel.org/r/159643094925.4062302.14979872973043772305.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Suggested-by: Rafael J. Wysocki Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Ard Biesheuvel Cc: Benjamin Herrenschmidt Cc: Ben Skeggs Cc: Borislav Petkov Cc: Brice Goglin Cc: Catalin Marinas Cc: Daniel Vetter Cc: Dave Hansen Cc: Dave Jiang Cc: David Airlie Cc: David Hildenbrand Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jeff Moyer Cc: Jia He Cc: Joao Martins Cc: Jonathan Cameron Cc: Michael Ellerman Cc: Mike Rapoport Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Vishal Verma Cc: Wei Yang Cc: Will Deacon Signed-off-by: Andrew Morton --- arch/x86/include/asm/numa.h | 8 +++++++- arch/x86/mm/numa.c | 8 ++------ arch/x86/mm/numa_emulation.c | 3 ++- arch/x86/xen/enlighten_pv.c | 2 +- drivers/acpi/numa/srat.c | 9 +++++++-- include/acpi/acpi_numa.h | 6 +++++- 6 files changed, 24 insertions(+), 12 deletions(-) --- a/arch/x86/include/asm/numa.h~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/arch/x86/include/asm/numa.h @@ -3,6 +3,7 @@ #define _ASM_X86_NUMA_H #include +#include #include #include @@ -77,7 +78,12 @@ void debug_cpumask_set_cpu(int cpu, int #ifdef CONFIG_NUMA_EMU #define FAKE_NODE_MIN_SIZE ((u64)32 << 20) #define FAKE_NODE_MIN_HASH_MASK (~(FAKE_NODE_MIN_SIZE - 1UL)) -void numa_emu_cmdline(char *); +int numa_emu_cmdline(char *str); +#else /* CONFIG_NUMA_EMU */ +static inline int numa_emu_cmdline(char *str) +{ + return -EINVAL; +} #endif /* CONFIG_NUMA_EMU */ #endif /* _ASM_X86_NUMA_H */ --- a/arch/x86/mm/numa.c~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/arch/x86/mm/numa.c @@ -37,14 +37,10 @@ static __init int numa_setup(char *opt) return -EINVAL; if (!strncmp(opt, "off", 3)) numa_off = 1; -#ifdef CONFIG_NUMA_EMU if (!strncmp(opt, "fake=", 5)) - numa_emu_cmdline(opt + 5); -#endif -#ifdef CONFIG_ACPI_NUMA + return numa_emu_cmdline(opt + 5); if (!strncmp(opt, "noacpi", 6)) - acpi_numa = -1; -#endif + disable_srat(); return 0; } early_param("numa", numa_setup); --- a/arch/x86/mm/numa_emulation.c~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/arch/x86/mm/numa_emulation.c @@ -13,9 +13,10 @@ static int emu_nid_to_phys[MAX_NUMNODES]; static char *emu_cmdline __initdata; -void __init numa_emu_cmdline(char *str) +int __init numa_emu_cmdline(char *str) { emu_cmdline = str; + return 0; } static int __init emu_find_memblk_by_nid(int nid, const struct numa_meminfo *mi) --- a/arch/x86/xen/enlighten_pv.c~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/arch/x86/xen/enlighten_pv.c @@ -1302,7 +1302,7 @@ asmlinkage __visible void __init xen_sta * any NUMA information the kernel tries to get from ACPI will * be meaningless. Prevent it from trying. */ - acpi_numa = -1; + disable_srat(); #endif WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv)); --- a/drivers/acpi/numa/srat.c~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/drivers/acpi/numa/srat.c @@ -27,7 +27,12 @@ static int node_to_pxm_map[MAX_NUMNODES] = { [0 ... MAX_NUMNODES - 1] = PXM_INVAL }; unsigned char acpi_srat_revision __initdata; -int acpi_numa __initdata; +static int acpi_numa __initdata; + +void __init disable_srat(void) +{ + acpi_numa = -1; +} int pxm_to_node(int pxm) { @@ -163,7 +168,7 @@ static int __init slit_valid(struct acpi void __init bad_srat(void) { pr_err("SRAT: SRAT not used.\n"); - acpi_numa = -1; + disable_srat(); } int __init srat_disabled(void) --- a/include/acpi/acpi_numa.h~x86-numa-cleanup-configuration-dependent-command-line-options +++ a/include/acpi/acpi_numa.h @@ -17,10 +17,14 @@ extern int pxm_to_node(int); extern int node_to_pxm(int); extern int acpi_map_pxm_to_node(int); extern unsigned char acpi_srat_revision; -extern int acpi_numa __initdata; +extern void disable_srat(void); extern void bad_srat(void); extern int srat_disabled(void); +#else /* CONFIG_ACPI_NUMA */ +static inline void disable_srat(void) +{ +} #endif /* CONFIG_ACPI_NUMA */ #endif /* __ACP_NUMA_H */ _ Patches currently in -mm which might be from dan.j.williams@intel.com are x86-numa-cleanup-configuration-dependent-command-line-options.patch x86-numa-add-nohmat-option.patch efi-fake_mem-arrange-for-a-resource-entry-per-efi_fake_mem-instance.patch acpi-hmat-refactor-hmat_register_target_device-to-hmem_register_device.patch resource-report-parent-to-walk_iomem_res_desc-callback.patch mm-memory_hotplug-introduce-default-phys_to_target_node-implementation.patch acpi-hmat-attach-a-device-for-each-soft-reserved-range.patch device-dax-drop-the-dax_regionpfn_flags-attribute.patch device-dax-move-instance-creation-parameters-to-struct-dev_dax_data.patch device-dax-make-pgmap-optional-for-instance-creation.patch device-dax-kill-dax_kmem_res.patch device-dax-add-an-allocation-interface-for-device-dax-instances.patch device-dax-introduce-seed-devices.patch drivers-base-make-device_find_child_by_name-compatible-with-sysfs-inputs.patch device-dax-add-resize-support.patch mm-memremap_pages-convert-to-struct-range.patch mm-memremap_pages-support-multiple-ranges-per-invocation.patch device-dax-add-dis-contiguous-resource-support.patch device-dax-introduce-mapping-devices.patch