linux-kernel - Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Apr 2015 14:53:38 +0200
From:	Christoph Hellwig <hch@....de>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Boaz Harrosh <boaz@...xistor.com>, Neil Brown <neilb@...e.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Jens Axboe <axboe@...com>, "H. Peter Anvin" <hpa@...or.com>,
	Christoph Hellwig <hch@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem

[I haven't much time to look through the patches, so only high level
 hand wavey comments for now, sorry..]

On Mon, Apr 20, 2015 at 01:14:42AM -0700, Dan Williams wrote:
> > 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??
> 
> There's only three core properties of NVDIMMs that this implementation
> cares about.
> 
> 1/ directly mapped interleaved persistent memory (PMEM)
> 2/ indirect mmio aperture accessed (windowed) persistent memory (BLK)
> 3/ the possibility that those 2 access modes may alias the same
> on-media addresses
> 
> Most of complexity of the implementation is dealing with aspect 3, but
> that complexity can and is bypassed in places.
> 
> > Firmware might be a discovery method - or not. A non-volatile device
> > might be e820 enumerated, or PCI discovered - potentially with all
> > discovery handled by the driver.
> 
> PCI attached non-volatile memory is NVMe.  ND is handling address
> ranges that support direct cpu load store.

But those can't be attached in all kinds of different ways.  It's not like
this is a new thing - they've been used in Storage OEM systems for a long
time, both on Intel platforms and other CPUs.

And the current pmem.c can also handle cases like a PCI card exposing
a large mmio region that can be used as persistent memory.

So a big vote from me into namving this the pmem subsystem and trying
to have names not too tied to one specific firmware interface.  Once
I'll go through this in more detail I'll comment more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/