From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pankaj Gupta Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver Date: Thu, 12 Oct 2017 18:18:39 -0400 (EDT) Message-ID: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Kevin Wolf , Rik van Riel , Jan Kara , Xiao Guangrong , KVM list , David Hildenbrand , linux-nvdimm , Ross Zwisler , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qemu Developers , Linux MM , Stefan Hajnoczi , Paolo Bonzini , Nitesh Narayan Lal List-Id: linux-nvdimm@lists.01.org > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta wrote: > > > >> > This patch adds virtio-pmem driver for KVM guest. > >> > Guest reads the persistent memory range information > >> > over virtio bus from Qemu and reserves the range > >> > as persistent memory. Guest also allocates a block > >> > device corresponding to the pmem range which later > >> > can be accessed with DAX compatible file systems. > >> > Idea is to use the virtio channel between guest and > >> > host to perform the block device flush for guest pmem > >> > DAX device. > >> > > >> > There is work to do including DAX file system support > >> > and other advanced features. > >> > > >> > Signed-off-by: Pankaj Gupta > >> > --- > >> > drivers/virtio/Kconfig | 10 ++ > >> > drivers/virtio/Makefile | 1 + > >> > drivers/virtio/virtio_pmem.c | 322 > >> > +++++++++++++++++++++++++++++++++++++++ > >> > include/uapi/linux/virtio_pmem.h | 55 +++++++ > >> > 4 files changed, 388 insertions(+) > >> > create mode 100644 drivers/virtio/virtio_pmem.c > >> > create mode 100644 include/uapi/linux/virtio_pmem.h > >> > > >> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >> > index cff773f15b7e..0192c4bda54b 100644 > >> > --- a/drivers/virtio/Kconfig > >> > +++ b/drivers/virtio/Kconfig > >> > @@ -38,6 +38,16 @@ config VIRTIO_PCI_LEGACY > >> > > >> > If unsure, say Y. > >> > > >> > +config VIRTIO_PMEM > >> > + tristate "Virtio pmem driver" > >> > + depends on VIRTIO > >> > + ---help--- > >> > + This driver adds persistent memory range within a KVM guest. > >> > >> I think we need to call this something other than persistent memory to > >> make it clear that this not memory where the persistence can be > >> managed from userspace. The persistence point always requires a driver > >> call, so this is something distinctly different than "persistent > >> memory". For example, it's a bug if this memory range ends up backing > >> a device-dax range in the guest where there is no such thing as a > >> driver callback to perform the flushing. How does this solution > >> protect against that scenario? > > > > yes, you are right we are not providing device_dax in this case so it > > should > > be clear from name. Any suggestion for name? > > So currently /proc/iomem in a guest with a pmem device attached to a > namespace looks like this: > > c00000000-13bfffffff : Persistent Memory > c00000000-13bfffffff : namespace2.0 > > Can we call it "Virtio Shared Memory" to make it clear it is a > different beast than typical "Persistent Memory"? You can likely I think somewhere we need persistent keyword 'Virtio Persistent Memory' or so. > inject your own name into the resource tree the same way we do in the > NFIT driver. See acpi_nfit_insert_resource(). Sure! thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f197.google.com (mail-qk0-f197.google.com [209.85.220.197]) by kanga.kvack.org (Postfix) with ESMTP id D662C6B0033 for ; Thu, 12 Oct 2017 18:18:46 -0400 (EDT) Received: by mail-qk0-f197.google.com with SMTP id a12so3433345qka.7 for ; Thu, 12 Oct 2017 15:18:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id m34si4661982qtm.3.2017.10.12.15.18.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 15:18:46 -0700 (PDT) Date: Thu, 12 Oct 2017 18:18:39 -0400 (EDT) From: Pankaj Gupta Message-ID: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Rik van Riel , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta wrote: > > > >> > This patch adds virtio-pmem driver for KVM guest. > >> > Guest reads the persistent memory range information > >> > over virtio bus from Qemu and reserves the range > >> > as persistent memory. Guest also allocates a block > >> > device corresponding to the pmem range which later > >> > can be accessed with DAX compatible file systems. > >> > Idea is to use the virtio channel between guest and > >> > host to perform the block device flush for guest pmem > >> > DAX device. > >> > > >> > There is work to do including DAX file system support > >> > and other advanced features. > >> > > >> > Signed-off-by: Pankaj Gupta > >> > --- > >> > drivers/virtio/Kconfig | 10 ++ > >> > drivers/virtio/Makefile | 1 + > >> > drivers/virtio/virtio_pmem.c | 322 > >> > +++++++++++++++++++++++++++++++++++++++ > >> > include/uapi/linux/virtio_pmem.h | 55 +++++++ > >> > 4 files changed, 388 insertions(+) > >> > create mode 100644 drivers/virtio/virtio_pmem.c > >> > create mode 100644 include/uapi/linux/virtio_pmem.h > >> > > >> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >> > index cff773f15b7e..0192c4bda54b 100644 > >> > --- a/drivers/virtio/Kconfig > >> > +++ b/drivers/virtio/Kconfig > >> > @@ -38,6 +38,16 @@ config VIRTIO_PCI_LEGACY > >> > > >> > If unsure, say Y. > >> > > >> > +config VIRTIO_PMEM > >> > + tristate "Virtio pmem driver" > >> > + depends on VIRTIO > >> > + ---help--- > >> > + This driver adds persistent memory range within a KVM guest. > >> > >> I think we need to call this something other than persistent memory to > >> make it clear that this not memory where the persistence can be > >> managed from userspace. The persistence point always requires a driver > >> call, so this is something distinctly different than "persistent > >> memory". For example, it's a bug if this memory range ends up backing > >> a device-dax range in the guest where there is no such thing as a > >> driver callback to perform the flushing. How does this solution > >> protect against that scenario? > > > > yes, you are right we are not providing device_dax in this case so it > > should > > be clear from name. Any suggestion for name? > > So currently /proc/iomem in a guest with a pmem device attached to a > namespace looks like this: > > c00000000-13bfffffff : Persistent Memory > c00000000-13bfffffff : namespace2.0 > > Can we call it "Virtio Shared Memory" to make it clear it is a > different beast than typical "Persistent Memory"? You can likely I think somewhere we need persistent keyword 'Virtio Persistent Memory' or so. > inject your own name into the resource tree the same way we do in the > NFIT driver. See acpi_nfit_insert_resource(). Sure! thank you. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755489AbdJLWSq (ORCPT ); Thu, 12 Oct 2017 18:18:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52202 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990AbdJLWSp (ORCPT ); Thu, 12 Oct 2017 18:18:45 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3248EC059B63 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pagupta@redhat.com Date: Thu, 12 Oct 2017 18:18:39 -0400 (EDT) From: Pankaj Gupta To: Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Rik van Riel , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong Message-ID: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.116.26, 10.4.195.4] Thread-Topic: add virtio-pmem driver Thread-Index: 4YGXAfqge+D8CUfXK1q5As6bKuooig== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 12 Oct 2017 22:18:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta wrote: > > > >> > This patch adds virtio-pmem driver for KVM guest. > >> > Guest reads the persistent memory range information > >> > over virtio bus from Qemu and reserves the range > >> > as persistent memory. Guest also allocates a block > >> > device corresponding to the pmem range which later > >> > can be accessed with DAX compatible file systems. > >> > Idea is to use the virtio channel between guest and > >> > host to perform the block device flush for guest pmem > >> > DAX device. > >> > > >> > There is work to do including DAX file system support > >> > and other advanced features. > >> > > >> > Signed-off-by: Pankaj Gupta > >> > --- > >> > drivers/virtio/Kconfig | 10 ++ > >> > drivers/virtio/Makefile | 1 + > >> > drivers/virtio/virtio_pmem.c | 322 > >> > +++++++++++++++++++++++++++++++++++++++ > >> > include/uapi/linux/virtio_pmem.h | 55 +++++++ > >> > 4 files changed, 388 insertions(+) > >> > create mode 100644 drivers/virtio/virtio_pmem.c > >> > create mode 100644 include/uapi/linux/virtio_pmem.h > >> > > >> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >> > index cff773f15b7e..0192c4bda54b 100644 > >> > --- a/drivers/virtio/Kconfig > >> > +++ b/drivers/virtio/Kconfig > >> > @@ -38,6 +38,16 @@ config VIRTIO_PCI_LEGACY > >> > > >> > If unsure, say Y. > >> > > >> > +config VIRTIO_PMEM > >> > + tristate "Virtio pmem driver" > >> > + depends on VIRTIO > >> > + ---help--- > >> > + This driver adds persistent memory range within a KVM guest. > >> > >> I think we need to call this something other than persistent memory to > >> make it clear that this not memory where the persistence can be > >> managed from userspace. The persistence point always requires a driver > >> call, so this is something distinctly different than "persistent > >> memory". For example, it's a bug if this memory range ends up backing > >> a device-dax range in the guest where there is no such thing as a > >> driver callback to perform the flushing. How does this solution > >> protect against that scenario? > > > > yes, you are right we are not providing device_dax in this case so it > > should > > be clear from name. Any suggestion for name? > > So currently /proc/iomem in a guest with a pmem device attached to a > namespace looks like this: > > c00000000-13bfffffff : Persistent Memory > c00000000-13bfffffff : namespace2.0 > > Can we call it "Virtio Shared Memory" to make it clear it is a > different beast than typical "Persistent Memory"? You can likely I think somewhere we need persistent keyword 'Virtio Persistent Memory' or so. > inject your own name into the resource tree the same way we do in the > NFIT driver. See acpi_nfit_insert_resource(). Sure! thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2loY-00023l-Hj for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:18:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2loV-0005zl-Co for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:18:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47916) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e2loV-0005zN-3S for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:18:47 -0400 Date: Thu, 12 Oct 2017 18:18:39 -0400 (EDT) From: Pankaj Gupta Message-ID: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 2/2] KVM: add virtio-pmem driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Rik van Riel , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta wrote: > > > >> > This patch adds virtio-pmem driver for KVM guest. > >> > Guest reads the persistent memory range information > >> > over virtio bus from Qemu and reserves the range > >> > as persistent memory. Guest also allocates a block > >> > device corresponding to the pmem range which later > >> > can be accessed with DAX compatible file systems. > >> > Idea is to use the virtio channel between guest and > >> > host to perform the block device flush for guest pmem > >> > DAX device. > >> > > >> > There is work to do including DAX file system support > >> > and other advanced features. > >> > > >> > Signed-off-by: Pankaj Gupta > >> > --- > >> > drivers/virtio/Kconfig | 10 ++ > >> > drivers/virtio/Makefile | 1 + > >> > drivers/virtio/virtio_pmem.c | 322 > >> > +++++++++++++++++++++++++++++++++++++++ > >> > include/uapi/linux/virtio_pmem.h | 55 +++++++ > >> > 4 files changed, 388 insertions(+) > >> > create mode 100644 drivers/virtio/virtio_pmem.c > >> > create mode 100644 include/uapi/linux/virtio_pmem.h > >> > > >> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >> > index cff773f15b7e..0192c4bda54b 100644 > >> > --- a/drivers/virtio/Kconfig > >> > +++ b/drivers/virtio/Kconfig > >> > @@ -38,6 +38,16 @@ config VIRTIO_PCI_LEGACY > >> > > >> > If unsure, say Y. > >> > > >> > +config VIRTIO_PMEM > >> > + tristate "Virtio pmem driver" > >> > + depends on VIRTIO > >> > + ---help--- > >> > + This driver adds persistent memory range within a KVM guest. > >> > >> I think we need to call this something other than persistent memory to > >> make it clear that this not memory where the persistence can be > >> managed from userspace. The persistence point always requires a driver > >> call, so this is something distinctly different than "persistent > >> memory". For example, it's a bug if this memory range ends up backing > >> a device-dax range in the guest where there is no such thing as a > >> driver callback to perform the flushing. How does this solution > >> protect against that scenario? > > > > yes, you are right we are not providing device_dax in this case so it > > should > > be clear from name. Any suggestion for name? > > So currently /proc/iomem in a guest with a pmem device attached to a > namespace looks like this: > > c00000000-13bfffffff : Persistent Memory > c00000000-13bfffffff : namespace2.0 > > Can we call it "Virtio Shared Memory" to make it clear it is a > different beast than typical "Persistent Memory"? You can likely I think somewhere we need persistent keyword 'Virtio Persistent Memory' or so. > inject your own name into the resource tree the same way we do in the > NFIT driver. See acpi_nfit_insert_resource(). Sure! thank you.