From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> Date: Tue, 28 Apr 2015 15:28:43 -0700 Message-ID: Subject: Re: [PATCH v2 00/20] libnd: non-volatile memory device support From: Dan Williams Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski 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 List-ID: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031220AbbD1W2w (ORCPT ); Tue, 28 Apr 2015 18:28:52 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:35840 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031183AbbD1W2p (ORCPT ); Tue, 28 Apr 2015 18:28:45 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> Date: Tue, 28 Apr 2015 15:28:43 -0700 Message-ID: Subject: Re: [PATCH v2 00/20] libnd: non-volatile memory device support From: Dan Williams To: Andy Lutomirski 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 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.