From patchwork Mon Feb 23 12:33:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boaz Harrosh X-Patchwork-Id: 5865311 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 373189F269 for ; Mon, 23 Feb 2015 12:34:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 452F920640 for ; Mon, 23 Feb 2015 12:33:59 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 432252063C for ; Mon, 23 Feb 2015 12:33:58 +0000 (UTC) Received: from ml01.vlan14.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 37FEB8118B; Mon, 23 Feb 2015 04:33:58 -0800 (PST) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 61EE18118B for ; Mon, 23 Feb 2015 04:33:57 -0800 (PST) Received: by wevl61 with SMTP id l61so13518610wev.2 for ; Mon, 23 Feb 2015 04:33:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vnzsMUpI7dkmHfKehb+XPMdNJO+X8uvoxpAMDBK/ISE=; b=jveGUiwIUX+TU0biUihJsKYFL+j/WOVnwdjsUjlr/PzVoS02PK3SolrHWV0JcNLSrz iOzo5qDU4LVPiWkF8dS3noy2vOIfgj3/oFqGGbsgVBZSpME4GBGKqxaIGA75IxT3ni1w nnxZDB7I1e79lbgMUN+tQAG8vuTJcjygxy4FANjSIJYrp7Y0g4m/zTIpIg4AA/PKt0z3 S1SY5ToSuwWHQmwNoowEDqA5FAj9l9+n+o2o7ce1KLGLux8fgzNTU+NnrnqayFqCe93T fWV4mIHvyxJPTXkUIn07Q1RTP5fA/nT5fUKZ7dmhRMJUiyYKO0Y2TIUam0ga1FJ1GTR9 c5bQ== X-Gm-Message-State: ALoCoQmaIgSdgS0IJVEbcxhD6kisPM+KrBKvEgfoWfgZVMjpmGxF9Dft32L/fYjCoWCBNnHA/+F7 X-Received: by 10.194.95.66 with SMTP id di2mr21817514wjb.57.1424694790517; Mon, 23 Feb 2015 04:33:10 -0800 (PST) Received: from [10.0.0.5] ([207.232.55.62]) by mx.google.com with ESMTPSA id a1sm55388690wjs.40.2015.02.23.04.33.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 04:33:09 -0800 (PST) Message-ID: <54EB1E03.4010306@plexistor.com> Date: Mon, 23 Feb 2015 14:33:07 +0200 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ingo Molnar , Ross Zwisler , x86@kernel.org, linux-kernel , "Roger C. Pao" , Dan Williams , Thomas Gleixner , Linus Torvalds , linux-nvdimm , "H. Peter Anvin" , Matthew Wilcox , Andy Lutomirski , Christoph Hellwig References: <54EB1D33.3050107@plexistor.com> In-Reply-To: <54EB1D33.3050107@plexistor.com> Subject: [Linux-nvdimm] [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There is something not very nice (Gentlemen nice) In current e820.c code. At Multiple places for example like (@ memblock_x86_fill()) it will add the different memory resources *except the E820_RESERVED type* Then at e820_reserve_resources() it will mark all !E820_RESERVED as busy. This is all fine when we have only the known types one of: E820_RESERVED_KERN: E820_RAM: E820_ACPI: E820_NVS: E820_UNUSABLE: E820_RESERVED: But if the system encounters a brand new memory type it will not add it to any memory list, But will proceed to mark it BUSY. So now any other Driver in the system that does know how to deal with this new type, is not able to call request_mem_region_exclusive() on this new type because it is hard coded BUSY even though nothing really uses it. So make any unknown type behave like E820_RESERVED memory, it will show up as available to first caller of request_mem_region_exclusive(). I Also change the string representation of an unknown type from "reserved" (So to not confuse with memmap "reserved" region). And call it "reserved-unknown" I wish I could return "reserved-type-X" But this is not possible because one must return a constant, code-segment, string. (NOTE: These unknown-types where called "reserved" in /proc/iomem and in dmesg but behaved differently. What this patch does is name them differently but let them behave the same) By Popular demand An Extra WARNING message is printed if an "UNKNOWN" is found. It will look like this: e820: WARNING [mem 0x100000000-0x1ffffffff] is unknown type 12 An example of such "UNKNOWN" type is the not Standard type-12 DDR3-NvDIMM which is used by multiple vendors for a while now. (Estimated 100ds of thousands sold world wide) CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x86@kernel.org CC: Dan Williams CC: Matthew Wilcox CC: Christoph Hellwig CC: Andy Lutomirski Signed-off-by: Boaz Harrosh --- arch/x86/kernel/e820.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 46201de..1a8a1c3 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -104,6 +104,21 @@ int __init e820_all_mapped(u64 start, u64 end, unsigned type) return 0; } +static bool _is_unknown_type(int e820_type) +{ + switch (e820_type) { + case E820_RESERVED_KERN: + case E820_RAM: + case E820_ACPI: + case E820_NVS: + case E820_UNUSABLE: + case E820_RESERVED: + return false; + default: + return true; + } +} + /* * Add a memory region to the kernel e820 map. */ @@ -119,6 +134,11 @@ static void __init __e820_add_region(struct e820map *e820x, u64 start, u64 size, return; } + if (unlikely(_is_unknown_type(type))) + pr_warn("e820: WARNING [mem %#010llx-%#010llx] is unknown type %d\n", + (unsigned long long) start, + (unsigned long long) (start + size - 1), type); + e820x->map[x].addr = start; e820x->map[x].size = size; e820x->map[x].type = type; @@ -907,10 +927,16 @@ static inline const char *e820_type_to_string(int e820_type) case E820_ACPI: return "ACPI Tables"; case E820_NVS: return "ACPI Non-volatile Storage"; case E820_UNUSABLE: return "Unusable memory"; - default: return "reserved"; + case E820_RESERVED: return "reserved"; + default: return "reserved-unkown"; } } +static bool _is_reserved_type(int e820_type) +{ + return (e820_type == E820_RESERVED) || _is_unknown_type(e820_type); +} + /* * Mark e820 reserved areas as busy for the resource manager. */ @@ -940,7 +966,8 @@ void __init e820_reserve_resources(void) * pci device BAR resource and insert them later in * pcibios_resource_survey() */ - if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) { + if (!_is_reserved_type(e820.map[i].type) || + res->start < (1ULL<<20)) { res->flags |= IORESOURCE_BUSY; insert_resource(&iomem_resource, res); }