Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031275AbbD1XFn (ORCPT ); Tue, 28 Apr 2015 19:05:43 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:33595 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031139AbbD1XFj (ORCPT ); Tue, 28 Apr 2015 19:05:39 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> From: Andy Lutomirski Date: Tue, 28 Apr 2015 16:05:17 -0700 Message-ID: Subject: Re: [PATCH v2 00/20] libnd: non-volatile memory device support To: Dan Williams Cc: linux-nvdimm , Boaz Harrosh , Neil Brown , Dave Chinner , "H. Peter Anvin" , Ingo Molnar , "Rafael J. Wysocki" , Robert Moore , Christoph Hellwig , Linux ACPI , Jeff Moyer , Nicholas Moulin , Matthew Wilcox , Ross Zwisler , Vishal Verma , Jens Axboe , Borislav Petkov , Thomas Gleixner , Greg KH , "linux-kernel@vger.kernel.org" , Andrew Morton , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3687 Lines: 74 On Tue, Apr 28, 2015 at 3:28 PM, Dan Williams wrote: > On Tue, Apr 28, 2015 at 2:06 PM, Andy Lutomirski wrote: >> On Tue, Apr 28, 2015 at 1:59 PM, Dan Williams wrote: >>> On Tue, Apr 28, 2015 at 1:52 PM, Andy Lutomirski wrote: >>>> On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams wrote: >>>>> Changes since v1 [1]: Incorporates feedback received prior to April 24. >>>>> >>>>> 1/ Ingo said [2]: >>>>> >>>>> "So why on earth is this whole concept and the naming itself >>>>> ('drivers/block/nd/' stands for 'NFIT Defined', apparently) >>>>> revolving around a specific 'firmware' mindset and revolving >>>>> around specific, weirdly named, overly complicated looking >>>>> firmware interfaces that come with their own new weird >>>>> glossary??" >>>>> >>>>> Indeed, we of course consulted the NFIT specification to determine >>>>> the shape of the sub-system, but then let its terms and data >>>>> structures permeate too deep into the implementation. That is fixed >>>>> now with all NFIT specifics factored out into acpi.c. The NFIT is no >>>>> longer required reading to review libnd. Only three concepts are >>>>> needed: >>>>> >>>>> i/ PMEM - contiguous memory range where cpu stores are >>>>> persistent once they are flushed through the memory >>>>> controller. >>>>> >>>>> ii/ BLK - mmio apertures (sliding windows) that can be >>>>> programmed to access an aperture's-worth of persistent >>>>> media at a time. >>>>> >>>>> iii/ DPA - "dimm-physical-address", address space local to a >>>>> dimm. A dimm may provide both PMEM-mode and BLK-mode >>>>> access to a range of DPA. libnd manages allocation of DPA >>>>> to either PMEM or BLK-namespaces to resolve this aliasing. >>>> >>>> Mostly for my understanding: is there a name for "address relative to >>>> the address lines on the DIMM"? That is, a DIMM that exposes 8 GB of >>>> apparent physical memory, possibly interleaved, broken up, or weirdly >>>> remapped by the memory controller, would still have addresses between >>>> 0 and 8 GB. Some of those might be PMEM windows, some might be MMIO, >>>> some might be BLK apertures, etc. >>>> >>>> IIUC "DPA" refers to actual addressable storage, not this type of address? >>> >>> No, DPA is exactly as you describe above. You can't directly access >>> it except through a PMEM mapping (possibly interleaved with DPA from >>> other DIMMs) or a BLK aperture (mmio window into DPA). >> >> So the thing I'm describing has no name, then? Oh, well. > > What? The thing you are describing *is* DPA. I'm confused. Here are the two things I have in mind: 1. An address into on-DIMM storage. If I have a DIMM that is mapped to 8 GB of SPA but has 64 GB of usable storage (accessed through BLK apertures, say), then this address runs from 0 to 64 GB. 2. An address into the DIMM's view of physical address space. If I have a DIMM that is mapped to 8 GB of SPA but has 64 GB of usable storage (accessed through BLK apertures, say), then this address runs from 0 to 8 GB. There's a one-to-one mapping between SPA and this type of address. Since you said "a dimm may provide both PMEM-mode and BLK-mode access to a range of DPA.," I thought that DPA was #1. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/