All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Pankaj Gupta <pagupta@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	qemu-devel@nongnu.org, linux-nvdimm@ml01.01.org,
	linux-mm@kvack.org, kwolf@redhat.com, haozhong.zhang@intel.com,
	jack@suse.cz, xiaoguangrong.eric@gmail.com, riel@surriel.com,
	niteshnarayanlal@hotmail.com, david@redhat.com,
	ross.zwisler@intel.com, lcapitulino@redhat.com,
	hch@infradead.org, mst@redhat.com, stefanha@redhat.com,
	imammedo@redhat.com, marcel@redhat.com, pbonzini@redhat.com,
	dan.j.williams@intel.com, nilal@redhat.com
Subject: Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver
Date: Thu, 26 Apr 2018 14:12:36 +0100	[thread overview]
Message-ID: <20180426131236.GA30991@stefanha-x1.localdomain> (raw)
In-Reply-To: <20180425112415.12327-2-pagupta@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 9861 bytes --]

On Wed, Apr 25, 2018 at 04:54:13PM +0530, Pankaj Gupta wrote:
> This patch adds virtio-pmem driver for KVM 
> guest. 
> 
> Guest reads the persistent memory range 
> information from Qemu over VIRTIO and registers 
> it on nvdimm_bus. It also creates a nd_region 
> object with the persistent memory range 
> information so that existing 'nvdimm/pmem' 
> driver can reserve this into system memory map. 
> This way 'virtio-pmem' driver uses existing 
> functionality of pmem driver to register persistent 
> memory compatible for DAX capable filesystems.
> 
> This also provides function to perform guest flush 
> over VIRTIO from 'pmem' driver when userspace 
> performs flush on DAX memory range.
> 
> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> ---
>  drivers/virtio/Kconfig           |  12 ++++
>  drivers/virtio/Makefile          |   1 +
>  drivers/virtio/virtio_pmem.c     | 118 +++++++++++++++++++++++++++++++++++++++
>  include/linux/libnvdimm.h        |   4 ++
>  include/uapi/linux/virtio_ids.h  |   1 +
>  include/uapi/linux/virtio_pmem.h |  58 +++++++++++++++++++
>  6 files changed, 194 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 3589764..879335d 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -42,6 +42,18 @@ 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 to nd_region and registers
> +	 with nvdimm bus. NVDIMM 'pmem' driver later allocates a persistent
> +	 memory range on the memory information added by this driver. In addition
> +	 to this, 'virtio-pmem' driver also provides a paravirt flushing interface
> +	 from guest to host.
> +
> +	 If unsure, say M.
> +
>  config VIRTIO_BALLOON
>  	tristate "Virtio balloon driver"
>  	depends on VIRTIO
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 3a2b5c5..cbe91c6 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
>  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
>  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
>  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> +obj-$(CONFIG_VIRTIO_PMEM) += virtio_pmem.o
> diff --git a/drivers/virtio/virtio_pmem.c b/drivers/virtio/virtio_pmem.c
> new file mode 100644
> index 0000000..0906d2d
> --- /dev/null
> +++ b/drivers/virtio/virtio_pmem.c
> @@ -0,0 +1,118 @@

SPDX license line?  See Documentation/process/license-rules.rst.

> +/* Virtio pmem Driver
> + *
> + * Discovers persitent memory range information

s/persitent/persistent/

> + * from host and provides a virtio based flushing
> + * interface.
> + */
> +
> +#include <linux/virtio.h>
> +#include <linux/swap.h>
> +#include <linux/workqueue.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/oom.h>
> +#include <linux/wait.h>
> +#include <linux/magic.h>
> +#include <linux/virtio_pmem.h>
> +#include <linux/libnvdimm.h>

Are all these headers really needed?  delay.h?  oom.h?

> +
> +static int init_vq(struct virtio_pmem *vpmem)
> +{
> +	struct virtqueue *vq;
> +
> +	/* single vq */
> +	vpmem->req_vq = vq = virtio_find_single_vq(vpmem->vdev,
> +				NULL, "flush_queue");
> +
> +	if (IS_ERR(vq))
> +		return PTR_ERR(vq);
> +
> +	return 0;
> +};
> +
> +static int virtio_pmem_probe(struct virtio_device *vdev)
> +{
> +	int err = 0;
> +	struct resource res;
> +	struct virtio_pmem *vpmem;
> +	struct nvdimm_bus *nvdimm_bus;
> +	struct nd_region_desc ndr_desc;
> +	int nid = dev_to_node(&vdev->dev);
> +	static struct nvdimm_bus_descriptor nd_desc;
> +
> +	if (!vdev->config->get) {
> +		dev_err(&vdev->dev, "%s failure: config disabled\n",
> +			__func__);
> +		return -EINVAL;
> +	}
> +
> +	vdev->priv = vpmem = devm_kzalloc(&vdev->dev, sizeof(*vpmem),
> +			GFP_KERNEL);
> +	if (!vpmem) {
> +		err = -ENOMEM;
> +		goto out;
> +	}
> +
> +	vpmem->vdev = vdev;
> +	err = init_vq(vpmem);
> +	if (err)
> +		goto out;
> +
> +	virtio_cread(vpmem->vdev, struct virtio_pmem_config,
> +			start, &vpmem->start);
> +	virtio_cread(vpmem->vdev, struct virtio_pmem_config,
> +			size, &vpmem->size);
> +
> +	res.start = vpmem->start;
> +	res.end   = vpmem->start + vpmem->size-1;
> +
> +	memset(&nd_desc, 0, sizeof(nd_desc));
> +	nd_desc.provider_name = "virtio-pmem";
> +	nd_desc.module = THIS_MODULE;
> +	nvdimm_bus = nvdimm_bus_register(&vdev->dev, &nd_desc);
> +
> +	if (!nvdimm_bus)
> +		goto out_nd;
> +	dev_set_drvdata(&vdev->dev, nvdimm_bus);
> +
> +	memset(&ndr_desc, 0, sizeof(ndr_desc));
> +	ndr_desc.res = &res;
> +	ndr_desc.numa_node = nid;
> +	set_bit(ND_REGION_PAGEMAP, &ndr_desc.flags);
> +	set_bit(ND_REGION_VIRTIO, &ndr_desc.flags);
> +
> +	if (!nvdimm_pmem_region_create(nvdimm_bus, &ndr_desc))
> +		goto out_nd;
> +
> +	virtio_device_ready(vdev);
> +	return 0;
> +
> +out_nd:
> +	nvdimm_bus_unregister(nvdimm_bus);
> +out:
> +	dev_err(&vdev->dev, "failed to register virtio pmem memory\n");
> +	vdev->config->del_vqs(vdev);
> +	return err;
> +}
> +
> +static void virtio_pmem_remove(struct virtio_device *vdev)
> +{
> +	struct nvdimm_bus *nvdimm_bus = dev_get_drvdata(&vdev->dev);
> +
> +	nvdimm_bus_unregister(nvdimm_bus);
> +	vdev->config->del_vqs(vdev);
> +}
> +
> +static struct virtio_driver virtio_pmem_driver = {
> +	.driver.name		= KBUILD_MODNAME,
> +	.driver.owner		= THIS_MODULE,
> +	.id_table		= id_table,
> +	.probe			= virtio_pmem_probe,
> +	.remove			= virtio_pmem_remove,
> +};
> +
> +module_virtio_driver(virtio_pmem_driver);
> +MODULE_DEVICE_TABLE(virtio, id_table);
> +MODULE_DESCRIPTION("Virtio pmem driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> index 097072c..b1b7f14 100644
> --- a/include/linux/libnvdimm.h
> +++ b/include/linux/libnvdimm.h
> @@ -58,6 +58,10 @@ enum {
>  	 * (ADR)
>  	 */
>  	ND_REGION_PERSIST_MEMCTRL = 2,
> +	/*
> +	 * region flag indicating to use VIRTIO flush interface for pmem
> +	 */
> +	ND_REGION_VIRTIO = 3,

Can you add a generic flush callback to libnvdimm instead?  That way
virtio and other drivers can hook in without hardcoding knowledge of
these drivers into libnvdimm.

>  
>  	/* mark newly adjusted resources as requiring a label update */
>  	DPA_RESOURCE_ADJUSTED = 1 << 0,
> diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
> index 6d5c3b2..5ebd049 100644
> --- a/include/uapi/linux/virtio_ids.h
> +++ b/include/uapi/linux/virtio_ids.h
> @@ -43,5 +43,6 @@
>  #define VIRTIO_ID_INPUT        18 /* virtio input */
>  #define VIRTIO_ID_VSOCK        19 /* virtio vsock transport */
>  #define VIRTIO_ID_CRYPTO       20 /* virtio crypto */
> +#define VIRTIO_ID_PMEM         21 /* virtio pmem */
>  
>  #endif /* _LINUX_VIRTIO_IDS_H */
> diff --git a/include/uapi/linux/virtio_pmem.h b/include/uapi/linux/virtio_pmem.h
> new file mode 100644
> index 0000000..2ec27cb
> --- /dev/null
> +++ b/include/uapi/linux/virtio_pmem.h
> @@ -0,0 +1,58 @@
> +/* Virtio pmem Driver
> + *
> + * Discovers persitent memory range information

s/persitent/persistent/

> + * from host and provides a virtio based flushing
> + * interface.
> + */
> +
> +#ifndef _LINUX_VIRTIO_PMEM_H
> +#define _LINUX_VIRTIO_PMEM_H
> +
> +#include <linux/types.h>
> +#include <linux/virtio_types.h>
> +#include <linux/virtio_ids.h>
> +#include <linux/virtio_config.h>
> +#include <linux/virtio_ring.h>
> +
> +
> +struct virtio_pmem_config {
> +
> +	uint64_t start;
> +	uint64_t size;
> +};
> +
> +struct virtio_pmem {
> +
> +	struct virtio_device *vdev;
> +	struct virtqueue *req_vq;
> +
> +	uint64_t start;
> +	uint64_t size;
> +} __packed;

This is a userspace API header file, it should contain definitions that
userspace programs need.  struct virtio_pmem is a kernel-internal struct
that should not be in the uapi headers.

Only define virtio spec structs in this header file (e.g. config space,
request structs, etc).

> +static struct virtio_device_id id_table[] = {
> +	{ VIRTIO_ID_PMEM, VIRTIO_DEV_ANY_ID },
> +	{ 0 },
> +};

Why is static variable in the header file?

> +
> +void virtio_pmem_flush(struct device *dev)

This only implements flush command submission, not completion.  Maybe
the next patch will implement that but it's a little strange to only see
half of the flush operation.

Please put the whole flush operation in one patch so it can be reviewed
easily.  At this point I don't know if you've forgotten to implement
wait for completion.

> +{

Why is this function body in the header file?

> +	struct scatterlist sg;
> +	struct virtio_device *vdev  = dev_to_virtio(dev->parent->parent);
> +	struct virtio_pmem   *vpmem = vdev->priv;
> +	char *buf = "FLUSH";

I'm surprised this compiles without a warning.  String literals should
be constant but the char pointer isn't constant.

> +	int err;
> +
> +	sg_init_one(&sg, buf, sizeof(buf));
> +
> +	err = virtqueue_add_outbuf(vpmem->req_vq, &sg, 1, buf, GFP_KERNEL);
> +
> +	if (err) {
> +		dev_err(&vdev->dev, "failed to send command to virtio pmem device\n");
> +		return;
> +	}
> +
> +	virtqueue_kick(vpmem->req_vq);

Is any locking necessary?  Two CPUs must not invoke virtio_pmem_flush()
at the same time.  Not sure if anything guarantees this, maybe you're
relying on libnvdimm but I haven't checked.

> +};
> +
> +#endif
> -- 
> 2.9.3
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2018-04-26 13:12 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 11:24 [RFC v2 0/2] kvm "fake DAX" device flushing Pankaj Gupta
2018-04-25 11:24 ` [Qemu-devel] " Pankaj Gupta
2018-04-25 11:24 ` Pankaj Gupta
     [not found] ` <20180425112415.12327-1-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 11:24   ` [RFC v2 1/2] virtio: add pmem driver Pankaj Gupta
2018-04-25 11:24     ` [Qemu-devel] " Pankaj Gupta
2018-04-25 11:24     ` Pankaj Gupta
     [not found]     ` <20180425112415.12327-2-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 14:21       ` Dan Williams
2018-04-25 14:21         ` [Qemu-devel] " Dan Williams
2018-04-25 14:21         ` Dan Williams
     [not found]         ` <CAPcyv4hvrB08XPTbVK0xT2_1Xmaid=-v3OMxJVDTNwQucsOHLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-25 14:43           ` Dan Williams
2018-04-25 14:43             ` [Qemu-devel] " Dan Williams
2018-04-25 14:43             ` Dan Williams
     [not found]             ` <CAPcyv4hiowWozV527sQA_e4fdgCYbD6xfG==vepAqu0hxQEQcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-26 12:27               ` Jeff Moyer
2018-04-26 12:27                 ` [Qemu-devel] " Jeff Moyer
2018-04-26 12:27                 ` Jeff Moyer
2018-04-26 12:27                 ` Jeff Moyer
     [not found]                 ` <x49o9i6885e.fsf-RRHT56Q3PSP4kTEheFKJxxDDeQx5vsVwAInAS/Ez/D0@public.gmane.org>
2018-04-26 17:15                   ` [Qemu-devel] " Pankaj Gupta
2018-04-26 17:15                     ` Pankaj Gupta
     [not found]                     ` <1499190564.23017177.1524762938762.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-26 17:24                       ` Jeff Moyer
2018-04-26 17:24                         ` Jeff Moyer
2018-04-25 14:52       ` Michael S. Tsirkin
2018-04-25 14:52         ` [Qemu-devel] " Michael S. Tsirkin
2018-04-25 14:52         ` Michael S. Tsirkin
     [not found]         ` <20180425174705-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-04-25 15:11           ` [Qemu-devel] " Pankaj Gupta
2018-04-25 15:11             ` Pankaj Gupta
2018-04-26 13:12     ` Stefan Hajnoczi [this message]
     [not found]       ` <20180426131236.GA30991-lxVrvc10SDRcolVlb+j0YCZi+YwRKgec@public.gmane.org>
2018-04-26 15:44         ` Pankaj Gupta
2018-04-26 15:44           ` Pankaj Gupta
2018-04-27 13:31           ` Stefan Hajnoczi
     [not found]             ` <20180427133146.GB11150-lxVrvc10SDRcolVlb+j0YCZi+YwRKgec@public.gmane.org>
2018-04-28 10:48               ` Pankaj Gupta
2018-04-28 10:48                 ` Pankaj Gupta
2018-04-25 11:24   ` [RFC v2 2/2] pmem: device flush over VIRTIO Pankaj Gupta
2018-04-25 11:24     ` [Qemu-devel] " Pankaj Gupta
2018-04-25 11:24     ` Pankaj Gupta
     [not found]     ` <20180425112415.12327-3-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 14:23       ` Dan Williams
2018-04-25 14:23         ` [Qemu-devel] " Dan Williams
2018-04-25 14:23         ` Dan Williams
     [not found]         ` <CAPcyv4gpZzKfE7jY1peYOVd6sVhNz7jce1s_xNH_2Lt8AjRK-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-25 14:47           ` Pankaj Gupta
2018-04-25 14:47             ` [Qemu-devel] " Pankaj Gupta
2018-04-25 14:47             ` Pankaj Gupta
2018-04-26 13:15     ` Stefan Hajnoczi
2018-04-26 13:15       ` [Qemu-devel] " Stefan Hajnoczi
     [not found]       ` <20180426131517.GB30991-lxVrvc10SDRcolVlb+j0YCZi+YwRKgec@public.gmane.org>
2018-04-26 16:40         ` Pankaj Gupta
2018-04-26 16:40           ` [Qemu-devel] " Pankaj Gupta
2018-04-26 16:40           ` Pankaj Gupta
     [not found]           ` <58645254.23011245.1524760853269.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-26 16:57             ` Dan Williams
2018-04-26 16:57               ` [Qemu-devel] " Dan Williams
2018-04-26 16:57               ` Dan Williams
     [not found]               ` <CAPcyv4jv-hJNKJxak98T7aCnWztVEDTE8o=8fjvOrVmrTfyjdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-26 17:13                 ` Pankaj Gupta
2018-04-26 17:13                   ` [Qemu-devel] " Pankaj Gupta
2018-04-26 17:13                   ` Pankaj Gupta
2018-04-25 11:24   ` [RFC v2] qemu: Add virtio pmem device Pankaj Gupta
2018-04-25 11:24     ` [Qemu-devel] " Pankaj Gupta
2018-04-25 11:24     ` Pankaj Gupta
     [not found]     ` <20180425112415.12327-4-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 11:35       ` [Qemu-devel] " no-reply-isE1Te71pDtAfugRpC6u6w
2018-04-25 11:35         ` no-reply
2018-04-25 11:35         ` no-reply
2018-04-25 11:58         ` Pankaj Gupta
2018-04-25 11:58           ` Pankaj Gupta
2018-04-25 14:23           ` Eric Blake
2018-04-25 14:23             ` Eric Blake
     [not found]             ` <79f72139-0fcb-3d5e-a16c-24f3b5ee1a07-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 14:51               ` Pankaj Gupta
2018-04-25 14:51                 ` Pankaj Gupta
2018-04-25 11:46     ` no-reply
2018-04-25 11:46       ` no-reply
2018-04-25 11:46       ` no-reply
2018-04-25 14:25     ` Eric Blake
2018-04-25 14:25       ` Eric Blake
     [not found]       ` <25f3e433-cfa6-4a62-ba7f-47aef1119dfc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-25 14:55         ` Pankaj Gupta
2018-04-25 14:55           ` Pankaj Gupta
2018-04-26 13:24     ` Stefan Hajnoczi
2018-04-26 13:24       ` [Qemu-devel] " Stefan Hajnoczi
     [not found]       ` <20180426132406.GC30991-lxVrvc10SDRcolVlb+j0YCZi+YwRKgec@public.gmane.org>
2018-04-26 16:43         ` Pankaj Gupta
2018-04-26 16:43           ` Pankaj Gupta
2018-06-01 12:24   ` [Qemu-devel] [RFC v2 0/2] kvm "fake DAX" device flushing Igor Mammedov
2018-06-01 12:24     ` Igor Mammedov
     [not found]     ` <20180601142410.5c986f13-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-06-04  5:56       ` Pankaj Gupta
2018-06-04  5:56         ` Pankaj Gupta
2018-06-04  9:55       ` David Hildenbrand
2018-06-04  9:55         ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180426131236.GA30991@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=haozhong.zhang@intel.com \
    --cc=hch@infradead.org \
    --cc=imammedo@redhat.com \
    --cc=jack@suse.cz \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=nilal@redhat.com \
    --cc=niteshnarayanlal@hotmail.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riel@surriel.com \
    --cc=ross.zwisler@intel.com \
    --cc=stefanha@redhat.com \
    --cc=xiaoguangrong.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.