Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp2645422ima; Mon, 22 Oct 2018 13:21:29 -0700 (PDT) X-Google-Smtp-Source: ACcGV61R9OgiIdHipo9hZhUjD82u7xNqq1TdzYqumIBu7iE/YRZCZousHb5pNK95IFwkuq4Uh7qt X-Received: by 2002:a62:1095:: with SMTP id 21-v6mr46128486pfq.227.1540239689013; Mon, 22 Oct 2018 13:21:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540239688; cv=none; d=google.com; s=arc-20160816; b=C1gElvebowmg9waj63w5BIMDrxQloq2wIMfUe+DZ4Y9foyusDg00lBfXBGbfav4ynw P2SnnVgwT7Fat+7kA9TwW1Wn15nvwzE0FSphls9GoYaYUkQHAUCqp70kXWVUoL/q4bfu yq1oyTQrpG0/P8Zi3La17rebvU1LYbXwgfRVrnC87JlL0nAhw3xMizx8Hs0eJ16RvACY 3Jjw3UvR43oDTZd1tHuWPpPv4d6BHRnPQE4Hs2uArJlUZuGoDOegCAi7+mSGk349jU0S +/ZpiOx0pZkYMnFDHVGjSlDv/xM+bPMgrFOKkHFBCIalTqkQymxAvfAxwxt9aVvTPrBi gCUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject; bh=LkIfAHcPGuqatpzkJQXzIX0BljRNIJziyDVOi4USVeI=; b=QZA0HGfribzJn3g6tmoCuL0RqhnstZyr7TacF/L5TnfIKJOnwZkRH3eeTnsWJJvI/M NTu1UbkiOEb82rCJPhqU9oioCpO+XrlGe34CRRvQu1Ynf4IKXqAc4LwriTezP8plSNhH PYwP46xmg5lCcLadOBD13qZBmRD5mgMADJkowUaiVR2Acgy86/71VAuNKDOHoq4h/H5H wiynmHEGmIP7AscXycLFjAyHsmIna/OvwlPPeR8TGq6TY/Que655yx0/Zhw6TAGCTOSo YQZ9Hyht9D3Zi5MsdfQdyNFYLnVIlJK93w1mc/sb0FnEvdd3tYprxGQ+6BeyoJ9o4OZ7 dJZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n4-v6si34756882pga.568.2018.10.22.13.21.14; Mon, 22 Oct 2018 13:21:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728963AbeJWEip (ORCPT + 99 others); Tue, 23 Oct 2018 00:38:45 -0400 Received: from mga07.intel.com ([134.134.136.100]:37690 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbeJWEio (ORCPT ); Tue, 23 Oct 2018 00:38:44 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 13:18:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,413,1534834800"; d="scan'208";a="99739367" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by fmsmga004.fm.intel.com with ESMTP; 22 Oct 2018 13:18:45 -0700 Subject: [PATCH 6/9] mm/memory-hotplug: allow memory resources to be children To: linux-kernel@vger.kernel.org Cc: Dave Hansen , dan.j.williams@intel.com, dave.jiang@intel.com, zwisler@kernel.org, vishal.l.verma@intel.com, thomas.lendacky@amd.com, akpm@linux-foundation.org, mhocko@suse.com, linux-nvdimm@lists.01.org, linux-mm@kvack.org, ying.huang@intel.com, fengguang.wu@intel.com From: Dave Hansen Date: Mon, 22 Oct 2018 13:13:27 -0700 References: <20181022201317.8558C1D8@viggo.jf.intel.com> In-Reply-To: <20181022201317.8558C1D8@viggo.jf.intel.com> Message-Id: <20181022201327.F1642450@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The mm/resource.c code is used to manage the physical address space. We can view the current resource configuration in /proc/iomem. An example of this is at the bottom of this description. The nvdimm subsystem "owns" the physical address resources which map to persistent memory and has resources inserted for them as "Persistent Memory". We want to use this persistent memory, but as volatile memory, just like RAM. The best way to do this is to leave the existing resource in place, but add a "System RAM" resource underneath it. This clearly communicates the ownership relationship of this memory. The request_resource_conflict() API only deals with the top-level resources. Replace it with __request_region() which will search for !IORESOURCE_BUSY areas lower in the resource tree than the top level. We also rework the old error message a bit since we do not get the conflicting entry back: only an indication that we *had* a conflict. We *could* also simply truncate the existing top-level "Persistent Memory" resource and take over the released address space. But, this means that if we ever decide to hot-unplug the "RAM" and give it back, we need to recreate the original setup, which may mean going back to the BIOS tables. This should have no real effect on the existing collision detection because the areas that truly conflict should be marked IORESOURCE_BUSY. 00000000-00000fff : Reserved 00001000-0009fbff : System RAM 0009fc00-0009ffff : Reserved 000a0000-000bffff : PCI Bus 0000:00 000c0000-000c97ff : Video ROM 000c9800-000ca5ff : Adapter ROM 000f0000-000fffff : Reserved 000f0000-000fffff : System ROM 00100000-9fffffff : System RAM 01000000-01e071d0 : Kernel code 01e071d1-027dfdff : Kernel data 02dc6000-0305dfff : Kernel bss a0000000-afffffff : Persistent Memory (legacy) a0000000-a7ffffff : System RAM b0000000-bffdffff : System RAM bffe0000-bfffffff : Reserved c0000000-febfffff : PCI Bus 0000:00 Cc: Dan Williams Cc: Dave Jiang Cc: Ross Zwisler Cc: Vishal Verma Cc: Tom Lendacky Cc: Andrew Morton Cc: Michal Hocko Cc: linux-nvdimm@lists.01.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: Huang Ying Cc: Fengguang Wu --- b/mm/memory_hotplug.c | 31 ++++++++++++++----------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff -puN mm/memory_hotplug.c~mm-memory-hotplug-allow-memory-resource-to-be-child mm/memory_hotplug.c --- a/mm/memory_hotplug.c~mm-memory-hotplug-allow-memory-resource-to-be-child 2018-10-22 13:12:23.570930388 -0700 +++ b/mm/memory_hotplug.c 2018-10-22 13:12:23.573930388 -0700 @@ -99,24 +99,21 @@ void mem_hotplug_done(void) /* add this memory to iomem resource */ static struct resource *register_memory_resource(u64 start, u64 size) { - struct resource *res, *conflict; - res = kzalloc(sizeof(struct resource), GFP_KERNEL); - if (!res) - return ERR_PTR(-ENOMEM); + struct resource *res; + unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; + char resource_name[] = "System RAM"; - res->name = "System RAM"; - res->start = start; - res->end = start + size - 1; - res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; - conflict = request_resource_conflict(&iomem_resource, res); - if (conflict) { - if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) { - pr_debug("Device unaddressable memory block " - "memory hotplug at %#010llx !\n", - (unsigned long long)start); - } - pr_debug("System RAM resource %pR cannot be added\n", res); - kfree(res); + /* + * Request ownership of the new memory range. This might be + * a child of an existing resource that was present but + * not marked as busy. + */ + res = __request_region(&iomem_resource, start, size, + resource_name, flags); + + if (!res) { + pr_debug("Unable to reserve System RAM region: %016llx->%016llx\n", + start, start + size); return ERR_PTR(-EEXIST); } return res; _