From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver Date: Thu, 12 Oct 2017 18:27:29 -0400 Message-ID: <1507847249.21121.207.camel@redhat.com> References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Sender: owner-linux-mm@kvack.org To: Pankaj Gupta , Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong List-Id: linux-nvdimm@lists.01.org On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > 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. With "Virtio Block Backed Pmem" we could name the config option VIRTIO_BLOCK_PMEM The documentation text could make it clear to people that the image shows up as a disk image on the host, but as a pmem memory range in the 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 > > > > > > 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. Still hoping for better ideas than "Virtio Block Backed Pmem" :) -- 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 S1757008AbdJLW1j (ORCPT ); Thu, 12 Oct 2017 18:27:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40852 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756475AbdJLW1h (ORCPT ); Thu, 12 Oct 2017 18:27:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2320115557 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=riel@redhat.com Message-ID: <1507847249.21121.207.camel@redhat.com> Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver From: Rik van Riel To: Pankaj Gupta , Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong Date: Thu, 12 Oct 2017 18:27:29 -0400 In-Reply-To: <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> <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 12 Oct 2017 22:27:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > 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. With "Virtio Block Backed Pmem" we could name the config option VIRTIO_BLOCK_PMEM The documentation text could make it clear to people that the image shows up as a disk image on the host, but as a pmem memory range in the 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 > > > > > > 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. Still hoping for better ideas than "Virtio Block Backed Pmem" :) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver Date: Thu, 12 Oct 2017 18:27:29 -0400 Message-ID: <1507847249.21121.207.camel@redhat.com> References: <20171012155027.3277-1-pagupta@redhat.com> <20171012155027.3277-3-pagupta@redhat.com> <1567317495.19940236.1507843517318.JavaMail.zimbra@redhat.com> <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong To: Pankaj Gupta , Dan Williams Return-path: In-Reply-To: <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Sender: owner-linux-mm@kvack.org List-Id: kvm.vger.kernel.org On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > 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. With "Virtio Block Backed Pmem" we could name the config option VIRTIO_BLOCK_PMEM The documentation text could make it clear to people that the image shows up as a disk image on the host, but as a pmem memory range in the 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 > > > > > > 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. Still hoping for better ideas than "Virtio Block Backed Pmem" :) -- 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: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) by kanga.kvack.org (Postfix) with ESMTP id C182B6B0033 for ; Thu, 12 Oct 2017 18:27:38 -0400 (EDT) Received: by mail-qt0-f199.google.com with SMTP id z19so12952914qtg.21 for ; Thu, 12 Oct 2017 15:27:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id 62si362595qth.150.2017.10.12.15.27.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 15:27:38 -0700 (PDT) Message-ID: <1507847249.21121.207.camel@redhat.com> Subject: Re: [RFC 2/2] KVM: add virtio-pmem driver From: Rik van Riel Date: Thu, 12 Oct 2017 18:27:29 -0400 In-Reply-To: <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> <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Pankaj Gupta , Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta > > wrote: > > > > > > > > A This patch adds virtio-pmem driver for KVM guest. > > > > > A Guest reads the persistent memory range information > > > > > A over virtio bus from Qemu and reserves the range > > > > > A as persistent memory. Guest also allocates a block > > > > > A device corresponding to the pmem range which later > > > > > A can be accessed with DAX compatible file systems. > > > > > A Idea is to use the virtio channel between guest and > > > > > A host to perform the block device flush for guest pmem > > > > > A DAX device. > > > > > > > > > > A There is work to do including DAX file system support > > > > > A and other advanced features. > > > > > > > > > > Signed-off-by: Pankaj Gupta > > > > > --- > > > > > A drivers/virtio/KconfigA A A A A A A A A A A |A A 10 ++ > > > > > A drivers/virtio/MakefileA A A A A A A A A A |A A A 1 + > > > > > A drivers/virtio/virtio_pmem.cA A A A A | 322 > > > > > A +++++++++++++++++++++++++++++++++++++++ > > > > > A include/uapi/linux/virtio_pmem.h |A A 55 +++++++ > > > > > A 4 files changed, 388 insertions(+) > > > > > A create mode 100644 drivers/virtio/virtio_pmem.c > > > > > A 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 > > > > > > > > > > A A A A A A A A A A If unsure, say Y. > > > > > > > > > > +config VIRTIO_PMEM > > > > > +A A A A A A A tristate "Virtio pmem driver" > > > > > +A A A A A A A depends on VIRTIO > > > > > +A A A A A A A ---help--- > > > > > +A A A A A A A A This driver adds persistent memory range within a > > > > > KVM guest. With "Virtio Block Backed Pmem" we could name the config option VIRTIO_BLOCK_PMEM The documentation text could make it clear to people that the image shows up as a disk image on the host, but as a pmem memory range in the 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 > > > > > > So currently /proc/iomem in a guest with a pmem device attached to > > a > > namespace looks like this: > > > > A A A A c00000000-13bfffffff : Persistent Memory > > A A A A A A A c00000000-13bfffffff : namespace2.0 > > > > Can we call it "Virtio Shared Memory" to make it clear it is a > > different beast than typical "Persistent Memory"?A A You can likely > > I think somewhere we need persistent keyword 'Virtio Persistent > Memory' orA > so. Still hoping for better ideas than "Virtio Block Backed Pmem" :) -- 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 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2lx8-0004eL-6z for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:27:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2lx5-0001Vj-3w for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:27:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44214) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e2lx4-0001Uz-Rx for qemu-devel@nongnu.org; Thu, 12 Oct 2017 18:27:39 -0400 Message-ID: <1507847249.21121.207.camel@redhat.com> From: Rik van Riel Date: Thu, 12 Oct 2017 18:27:29 -0400 In-Reply-To: <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> <1363955128.19944709.1507846719987.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Pankaj Gupta , Dan Williams Cc: linux-kernel@vger.kernel.org, KVM list , Qemu Developers , linux-nvdimm , Linux MM , Jan Kara , Stefan Hajnoczi , Haozhong Zhang , Nitesh Narayan Lal , Kevin Wolf , Paolo Bonzini , Ross Zwisler , David Hildenbrand , Xiao Guangrong On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > >=20 > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta > > wrote: > > >=20 > > > > > =C2=A0 This patch adds virtio-pmem driver for KVM guest. > > > > > =C2=A0 Guest reads the persistent memory range information > > > > > =C2=A0 over virtio bus from Qemu and reserves the range > > > > > =C2=A0 as persistent memory. Guest also allocates a block > > > > > =C2=A0 device corresponding to the pmem range which later > > > > > =C2=A0 can be accessed with DAX compatible file systems. > > > > > =C2=A0 Idea is to use the virtio channel between guest and > > > > > =C2=A0 host to perform the block device flush for guest pmem > > > > > =C2=A0 DAX device. > > > > >=20 > > > > > =C2=A0 There is work to do including DAX file system support > > > > > =C2=A0 and other advanced features. > > > > >=20 > > > > > Signed-off-by: Pankaj Gupta > > > > > --- > > > > > =C2=A0drivers/virtio/Kconfig=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A010 ++ > > > > > =C2=A0drivers/virtio/Makefile=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A01 + > > > > > =C2=A0drivers/virtio/virtio_pmem.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | 322 > > > > > =C2=A0+++++++++++++++++++++++++++++++++++++++ > > > > > =C2=A0include/uapi/linux/virtio_pmem.h |=C2=A0=C2=A055 +++++++ > > > > > =C2=A04 files changed, 388 insertions(+) > > > > > =C2=A0create mode 100644 drivers/virtio/virtio_pmem.c > > > > > =C2=A0create mode 100644 include/uapi/linux/virtio_pmem.h > > > > >=20 > > > > > 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 > > > > >=20 > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0If = unsure, say Y. > > > > >=20 > > > > > +config VIRTIO_PMEM > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tristate "Virtio pme= m driver" > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0depends on VIRTIO > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0---help--- > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This driver ad= ds persistent memory range within a > > > > > KVM guest. With "Virtio Block Backed Pmem" we could name the config option VIRTIO_BLOCK_PMEM The documentation text could make it clear to people that the image shows up as a disk image on the host, but as a pmem memory range in the 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 > > > >=20 > > So currently /proc/iomem in a guest with a pmem device attached to > > a > > namespace looks like this: > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0c00000000-13bfffffff : Persistent Memory > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0c00000000-13bfffffff : name= space2.0 > >=20 > > Can we call it "Virtio Shared Memory" to make it clear it is a > > different beast than typical "Persistent Memory"?=C2=A0=C2=A0You can = likely >=20 > I think somewhere we need persistent keyword 'Virtio Persistent > Memory' or=C2=A0 > so. Still hoping for better ideas than "Virtio Block Backed Pmem" :)