From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753450AbbCZW7c (ORCPT ); Thu, 26 Mar 2015 18:59:32 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:36231 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753333AbbCZW73 (ORCPT ); Thu, 26 Mar 2015 18:59:29 -0400 MIME-Version: 1.0 In-Reply-To: <20150326093424.GA28217@lst.de> References: <1427358764-6126-1-git-send-email-hch@lst.de> <1427358764-6126-3-git-send-email-hch@lst.de> <20150326090215.GA11520@gmail.com> <20150326093424.GA28217@lst.de> Date: Thu, 26 Mar 2015 15:59:28 -0700 X-Google-Sender-Auth: jwZ1kDHRpyKMeQv3nFHvNlvpx4o Message-ID: Subject: Re: [PATCH 2/3] x86: add a is_e820_ram() helper From: Yinghai Lu To: Christoph Hellwig Cc: Ingo Molnar , linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List , "the arch/x86 maintainers" , ross.zwisler@linux.intel.com, Jens Axboe , boaz@plexistor.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2015 at 2:34 AM, Christoph Hellwig wrote: > On Thu, Mar 26, 2015 at 10:02:15AM +0100, Ingo Molnar wrote: >> This is_e820_ram() factoring out becomes really messy in patch #3. ... > Does this patch (replaces patches 2 and 3) look better to you? > > --- > From 4a6fdc8433559d649d7bf707f72aafa4488f2d23 Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig > Date: Wed, 25 Mar 2015 12:24:11 +0100 > Subject: x86: add support for the non-standard protected e820 type > > Various recent BIOSes support NVDIMMs or ADR using a non-standard > e820 memory type, and Intel supplied reference Linux code using this > type to various vendors. > > Wire this e820 table type up to export platform devices for the pmem > driver so that we can use it in Linux, and also provide a memmap= > argument to manually tag memory as protected, which can be used > if the BIOSs doesn't use the standard nonstandard interface, or > we just want to test the pmem driver with regular memory. > > Based on an earlier patch from Dave Jiang > ... > diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c > new file mode 100644 > index 0000000..f970048 > --- /dev/null > +++ b/arch/x86/kernel/pmem.c ... > + > +void __init reserve_pmem(void) > +{ > + int i; > + > + for (i = 0; i < e820.nr_map; i++) { > + struct e820entry *ei = &e820.map[i]; > + > + if (ei->type != E820_PRAM) > + continue; > + > + memblock_reserve(ei->addr, ei->addr + ei->size); > + max_pfn_mapped = init_memory_mapping( > + ei->addr < 1UL << 32 ? 1UL << 32 : ei->addr, > + ei->addr + ei->size); > + } > +} What do you want to get here? You did not modify memblock_x86_fill() to treat E820_PRAM as E820_RAM, so memblock will not have any entry for E820_PRAM, so you do not need to call memblock_reserve there. And the same time, init_memory_mapping() will call init_range_memory_mapping/for_each_mem_pfn_range() to set kernel mapping for memory range in memblock only. So here calling init_memory_mapping will not do anything. then just drop calling to that init_memory_mapping. --- so will not kernel mapping pmem, is that what you intended to have? After those two changes, You do not need this reserve_pmem at all. Just drop it. > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 0a2421c..f2bed2b 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1158,6 +1158,8 @@ void __init setup_arch(char **cmdline_p) > > early_acpi_boot_init(); > > + reserve_pmem(); > + Not needed. > initmem_init(); > dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT); Thanks Yinghai