From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen
Date: Mon, 1 Feb 2016 18:25:29 +0000
Message-ID: <56AFA319.8070801@citrix.com>
References: <20160201054414.GA25211@hz-desktop.sh.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20160201054414.GA25211@hz-desktop.sh.intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Haozhong Zhang <haozhong.zhang@intel.com>
Cc: Juergen Gross <jgross@suse.com>, Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>, Jun Nakajima <jun.nakajima@intel.com>, Xiao Guangrong <guangrong.xiao@linux.intel.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 01/02/16 05:44, Haozhong Zhang wrote:
> Hi,
>
> The following document describes the design of adding vNVDIMM support
> for Xen. Any comments are welcome.
>
> Thanks,
> Haozhong

Thankyou for doing this.  It is a very comprehensive document, and a
fantastic example for future similar situations.


To start with however, I would like to clear up my confusion over the
the usecases of pmem vs pblk.

pblk, using indirect access, is less efficient than pmem.  NVDIMMs
themselves are slower (and presumably more expensive) than equivalent
RAM, and presumably still has a finite number of write cycles,  so I
don't buy an argument suggesting that they are a plausible replacement
for real RAM.

I presume therefore that a system would only choose to use pblk mode in
situations where the host physical address space is a limiting factor. 
Are there other situations which I have overlooked?

Secondly, I presume that pmem vs pblk will be a firmware decision and
fixed from the point of view of the Operating System?

Thanks,

~Andrew