Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754095AbcJKQ7l (ORCPT ); Tue, 11 Oct 2016 12:59:41 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37307 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854AbcJKQ7i (ORCPT ); Tue, 11 Oct 2016 12:59:38 -0400 Date: Tue, 11 Oct 2016 12:58:11 -0400 From: Konrad Rzeszutek Wilk To: Dan Williams Cc: Jan Beulich , Juergen Gross , Haozhong Zhang , Xiao Guangrong , Arnd Bergmann , "linux-nvdimm@lists.01.org" , Boris Ostrovsky , andrew.cooper3@citrix.com, "linux-kernel@vger.kernel.org" , Stefano Stabellini , David Vrabel , Johannes Thumshirn , xen-devel@lists.xenproject.org, Andrew Morton , Ross Zwisler Subject: Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen Message-ID: <20161011165811.GO19349@localhost.localdomain> References: <20161010003523.4423-1-haozhong.zhang@intel.com> <57FCF26A02000078000F15E0@prv-mh.provo.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1929 Lines: 40 On Tue, Oct 11, 2016 at 08:53:33AM -0700, Dan Williams wrote: > On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote: > >>>> Andrew Cooper 10/10/16 6:44 PM >>> > >>On 10/10/16 01:35, Haozhong Zhang wrote: > >>> Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks: > >>> 1) Reserve an area on NVDIMM devices for Xen hypervisor to place > >>> memory management data structures, i.e. frame table and M2P table. > >>> 2) Report SPA ranges of NVDIMM devices and the reserved area to Xen > >>> hypervisor. > >> > >>However, I can't see any justification for 1). Dom0 should not be > >>involved in Xen's management of its own frame table and m2p. The mfns > >>making up the pmem/pblk regions should be treated just like any other > >>MMIO regions, and be handed wholesale to dom0 by default. > > > > That precludes the use as RAM extension, and I thought earlier rounds of > > discussion had got everyone in agreement that at least for the pmem case > > we will need some control data in Xen. > > The missing piece for me is why this reservation for control data > needs to be done in the libnvdimm core? I would expect that any dax Isn't it done this way with Linux? That is say if the machine has 4GB of RAM and the NVDIMM is in TB range. You want to put the 'struct page' for the NVDIMM ranges somewhere. That place can be in regions on the NVDIMM that ndctl can reserve. > capable file could be mapped and made available to a guest. This > includes /dev/ramX devices that are dax capable, but are external to > the libnvdimm sub-system. This is more of just keeping track of the ranges if say the DAX file is extremely fragmented and requires a lot of 'struct pages' to keep track of when stiching up the VMA. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel