From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiYpp-0004bY-D6 for qemu-devel@nongnu.org; Tue, 22 Mar 2016 22:47:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiYpm-0000oN-5c for qemu-devel@nongnu.org; Tue, 22 Mar 2016 22:47:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:54205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiYpl-0000o4-SL for qemu-devel@nongnu.org; Tue, 22 Mar 2016 22:47:46 -0400 References: <1458203581-59143-1-git-send-email-guangrong.xiao@linux.intel.com> <20160317100446.GA14062@stefanha-x1.localdomain> <20160322203058.GB31343@stefanha-x1.localdomain> From: Xiao Guangrong Message-ID: <56F203A0.70503@linux.intel.com> Date: Wed, 23 Mar 2016 10:46:56 +0800 MIME-Version: 1.0 In-Reply-To: <20160322203058.GB31343@stefanha-x1.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 00/15] NVDIMM: introduce nvdimm label support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Dan Williams Cc: ehabkost@redhat.com, KVM list , "Michael S. Tsirkin" , Gleb Natapov , Stefan Hajnoczi , mtosatti@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini , Igor Mammedov , rth@twiddle.net Sorry for the delay and i just come back from my vacation. On 03/23/2016 04:30 AM, Stefan Hajnoczi wrote: > On Tue, Mar 22, 2016 at 08:37:40AM -0700, Dan Williams wrote: >> On Thu, Mar 17, 2016 at 3:04 AM, Stefan Hajnoczi wrote: >>> On Thu, Mar 17, 2016 at 04:32:46PM +0800, Xiao Guangrong wrote: >>>> This patchset is against commit d4207b223eef3 (fw-cfg: support writeable >>>> blobs) on pci branch of Michael's git tree and can be found at: >>>> https://github.com/xiaogr/qemu.git nvdimm-label-v1 >>>> >>>> This is the last part of vNVDIMM implementation which introduces nvdimm >>>> label support >>>> >>>> Currently Linux NVDIMM driver does not support namespace operation on this >>>> kind of PMEM, apply below changes to support dynamical namespace: >>>> >>>> @@ -798,7 +823,8 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *a >>>> continue; >>>> } >>>> >>>> - if (nfit_mem->bdw && nfit_mem->memdev_pmem) >>>> + //if (nfit_mem->bdw && nfit_mem->memdev_pmem) >>>> + if (nfit_mem->memdev_pmem) >>>> flags |= NDD_ALIASING; >>> >>> Not a blocker for this patch series, but why does Linux require Block >>> Device Window to enable namespace support? >> >> A namespace label delineates aliased capacity between the pmem and >> block-window access mechanisms. If there is no aliased capacity then >> the size of the namespace can be directly derived from the nfit range >> and a label need not be considered. Contiguous (dax-capable) >> sub-divisions of pmem can be had via partitioning of the resulting >> gendisk. > > Xiao Guangrong: Given this new information, what is the purpose of the > QEMU patches for ACPI DSM and especially the namespace label support? > The initiation goal we introduced vlabel support is: | Yes, I see Linux driver supports label-less vNVDIMM that is exact current QEMU | doing. However, label-less is only Linux specific implementation (as it | completely bypasses namespace), other OS vendors (e.g Microsoft) will use label | storage to address their own requirements，or they do not follow namespace spec | at all. Another reason is that label is essential for PBLK support. I did not get the windows driver so far, so this is not tested on windows yet, just double checked with windows driver team, they told me that: "It always assumes there is one there so we will need to change how this works" So the update of windows side will be made. > The QEMU NVDIMM device only supports pmem so now I'm not sure we need > namespace labels or the ACPI DSM at all. > We are planing to support PBLK which "simulated BLK it can simply make one big aperture that happens to overlap the same address range as PMEM", it will "allow enabling BTT on BLK namespaces to support power-fail-safe sector updates for a filesystem on PMEM". The idea was contributed by Dan in our internal discussion...