From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-acpi@vger.kernel.org,
qemu-devel@nongnu.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, dan.j.williams@intel.com,
zwisler@kernel.org, vishal.l.verma@intel.com,
dave.jiang@intel.com, jasowang@redhat.com, willy@infradead.org,
rjw@rjwysocki.net, hch@infradead.org, lenb@kernel.org,
jack@suse.cz, tytso@mit.edu, adilger.kernel@dilger.ca,
darrick.wong@oracle.com, lcapitulino@redhat.com,
kwolf@redhat.com, imammedo@redhat.com, jmoyer@redhat.com,
nilal@redhat.com, riel@surriel.com, stefanha@redhat.com,
aarcange@redhat.com, david@fromorbit.com, cohuck@redhat.com,
xiaoguangrong.eric@gmail.com, pbonzini@redhat.com,
kilobyte@angband.pl, yuval.shaia@oracle.com, jstaron@google.com
Subject: Re: [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver
Date: Thu, 16 May 2019 09:59:09 -0400 [thread overview]
Message-ID: <20190516095618-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <9f6b1d8e-ef90-7d8b-56da-61a426953ba3@redhat.com>
On Wed, May 15, 2019 at 10:46:00PM +0200, David Hildenbrand wrote:
> > + vpmem->vdev = vdev;
> > + vdev->priv = vpmem;
> > + err = init_vq(vpmem);
> > + if (err) {
> > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n");
> > + goto out_err;
> > + }
> > +
> > + 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;
>
> nit: " - 1;"
>
> > + vpmem->nd_desc.provider_name = "virtio-pmem";
> > + vpmem->nd_desc.module = THIS_MODULE;
> > +
> > + vpmem->nvdimm_bus = nvdimm_bus_register(&vdev->dev,
> > + &vpmem->nd_desc);
> > + if (!vpmem->nvdimm_bus) {
> > + dev_err(&vdev->dev, "failed to register device with nvdimm_bus\n");
> > + err = -ENXIO;
> > + goto out_vq;
> > + }
> > +
> > + dev_set_drvdata(&vdev->dev, vpmem->nvdimm_bus);
> > +
> > + ndr_desc.res = &res;
> > + ndr_desc.numa_node = nid;
> > + ndr_desc.flush = async_pmem_flush;
> > + set_bit(ND_REGION_PAGEMAP, &ndr_desc.flags);
> > + set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
> > + nd_region = nvdimm_pmem_region_create(vpmem->nvdimm_bus, &ndr_desc);
> > + if (!nd_region) {
> > + dev_err(&vdev->dev, "failed to create nvdimm region\n");
> > + err = -ENXIO;
> > + goto out_nd;
> > + }
> > + nd_region->provider_data = dev_to_virtio(nd_region->dev.parent->parent);
> > + return 0;
> > +out_nd:
> > + nvdimm_bus_unregister(vpmem->nvdimm_bus);
> > +out_vq:
> > + vdev->config->del_vqs(vdev);
> > +out_err:
> > + 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);
> > + vdev->config->reset(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/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
> > new file mode 100644
> > index 000000000000..ab1da877575d
> > --- /dev/null
> > +++ b/drivers/nvdimm/virtio_pmem.h
> > @@ -0,0 +1,60 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * virtio_pmem.h: virtio pmem Driver
> > + *
> > + * Discovers persistent memory range information
> > + * from host and provides a virtio based flushing
> > + * interface.
> > + **/
> > +
> > +#ifndef _LINUX_VIRTIO_PMEM_H
> > +#define _LINUX_VIRTIO_PMEM_H
> > +
> > +#include <linux/virtio_ids.h>
> > +#include <linux/module.h>
> > +#include <linux/virtio_config.h>
> > +#include <uapi/linux/virtio_pmem.h>
> > +#include <linux/libnvdimm.h>
> > +#include <linux/spinlock.h>
> > +
> > +struct virtio_pmem_request {
> > + /* Host return status corresponding to flush request */
> > + int ret;
> > +
> > + /* command name*/
> > + char name[16];
>
> So ... why are we sending string commands and expect native-endianess
> integers and don't define a proper request/response structure + request
> types in include/uapi/linux/virtio_pmem.h like
passing names could be ok.
I missed the fact we return a native endian int.
Pls fix that.
>
> struct virtio_pmem_resp {
> __virtio32 ret;
> }
>
> #define VIRTIO_PMEM_REQ_TYPE_FLUSH 1
> struct virtio_pmem_req {
> __virtio16 type;
> }
>
> ... and this way we also define a proper endianess format for exchange
> and keep it extensible
>
> @MST, what's your take on this?
Extensions can always use feature bits so I don't think
it's a problem.
>
> --
>
> Thanks,
>
> David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-acpi@vger.kernel.org,
qemu-devel@nongnu.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, dan.j.williams@intel.com,
zwisler@kernel.org, vishal.l.verma@intel.com,
dave.jiang@intel.com, jasowang@redhat.com, willy@infradead.org,
rjw@rjwysocki.net, hch@infradead.org, lenb@kernel.org,
jack@suse.cz, tytso@mit.edu, adilger.kernel@dilger.ca,
darrick.wong@oracle.com, lcapitulino@redhat.com,
kwolf@redhat.com, imammedo@redhat.com, jmoyer@redhat.com,
nilal@redhat.com, riel@surriel.com, stefanha@redhat.com,
aarcange@redhat.com, david@fromorbit.com, cohuck@redhat.com,
xiaoguangrong.eric@gmail.com
Subject: Re: [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver
Date: Thu, 16 May 2019 09:59:09 -0400 [thread overview]
Message-ID: <20190516095618-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <9f6b1d8e-ef90-7d8b-56da-61a426953ba3@redhat.com>
On Wed, May 15, 2019 at 10:46:00PM +0200, David Hildenbrand wrote:
> > + vpmem->vdev = vdev;
> > + vdev->priv = vpmem;
> > + err = init_vq(vpmem);
> > + if (err) {
> > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n");
> > + goto out_err;
> > + }
> > +
> > + 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;
>
> nit: " - 1;"
>
> > + vpmem->nd_desc.provider_name = "virtio-pmem";
> > + vpmem->nd_desc.module = THIS_MODULE;
> > +
> > + vpmem->nvdimm_bus = nvdimm_bus_register(&vdev->dev,
> > + &vpmem->nd_desc);
> > + if (!vpmem->nvdimm_bus) {
> > + dev_err(&vdev->dev, "failed to register device with nvdimm_bus\n");
> > + err = -ENXIO;
> > + goto out_vq;
> > + }
> > +
> > + dev_set_drvdata(&vdev->dev, vpmem->nvdimm_bus);
> > +
> > + ndr_desc.res = &res;
> > + ndr_desc.numa_node = nid;
> > + ndr_desc.flush = async_pmem_flush;
> > + set_bit(ND_REGION_PAGEMAP, &ndr_desc.flags);
> > + set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
> > + nd_region = nvdimm_pmem_region_create(vpmem->nvdimm_bus, &ndr_desc);
> > + if (!nd_region) {
> > + dev_err(&vdev->dev, "failed to create nvdimm region\n");
> > + err = -ENXIO;
> > + goto out_nd;
> > + }
> > + nd_region->provider_data = dev_to_virtio(nd_region->dev.parent->parent);
> > + return 0;
> > +out_nd:
> > + nvdimm_bus_unregister(vpmem->nvdimm_bus);
> > +out_vq:
> > + vdev->config->del_vqs(vdev);
> > +out_err:
> > + 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);
> > + vdev->config->reset(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/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
> > new file mode 100644
> > index 000000000000..ab1da877575d
> > --- /dev/null
> > +++ b/drivers/nvdimm/virtio_pmem.h
> > @@ -0,0 +1,60 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * virtio_pmem.h: virtio pmem Driver
> > + *
> > + * Discovers persistent memory range information
> > + * from host and provides a virtio based flushing
> > + * interface.
> > + **/
> > +
> > +#ifndef _LINUX_VIRTIO_PMEM_H
> > +#define _LINUX_VIRTIO_PMEM_H
> > +
> > +#include <linux/virtio_ids.h>
> > +#include <linux/module.h>
> > +#include <linux/virtio_config.h>
> > +#include <uapi/linux/virtio_pmem.h>
> > +#include <linux/libnvdimm.h>
> > +#include <linux/spinlock.h>
> > +
> > +struct virtio_pmem_request {
> > + /* Host return status corresponding to flush request */
> > + int ret;
> > +
> > + /* command name*/
> > + char name[16];
>
> So ... why are we sending string commands and expect native-endianess
> integers and don't define a proper request/response structure + request
> types in include/uapi/linux/virtio_pmem.h like
passing names could be ok.
I missed the fact we return a native endian int.
Pls fix that.
>
> struct virtio_pmem_resp {
> __virtio32 ret;
> }
>
> #define VIRTIO_PMEM_REQ_TYPE_FLUSH 1
> struct virtio_pmem_req {
> __virtio16 type;
> }
>
> ... and this way we also define a proper endianess format for exchange
> and keep it extensible
>
> @MST, what's your take on this?
Extensions can always use feature bits so I don't think
it's a problem.
>
> --
>
> Thanks,
>
> David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pagupta@redhat.com>,
cohuck@redhat.com, jack@suse.cz, kvm@vger.kernel.org,
jasowang@redhat.com, david@fromorbit.com, qemu-devel@nongnu.org,
virtualization@lists.linux-foundation.org,
adilger.kernel@dilger.ca, zwisler@kernel.org,
aarcange@redhat.com, dave.jiang@intel.com, jstaron@google.com,
linux-nvdimm@lists.01.org, vishal.l.verma@intel.com,
willy@infradead.org, hch@infradead.org,
linux-acpi@vger.kernel.org, jmoyer@redhat.com,
linux-ext4@vger.kernel.org, lenb@kernel.org, kilobyte@angband.pl,
riel@surriel.com, yuval.shaia@oracle.com, stefanha@redhat.com,
pbonzini@redhat.com, dan.j.williams@intel.com,
lcapitulino@redhat.com, kwolf@redhat.com, nilal@redhat.com,
tytso@mit.edu, xiaoguangrong.eric@gmail.com,
darrick.wong@oracle.com, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, imammedo@redhat.com
Subject: Re: [Qemu-devel] [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver
Date: Thu, 16 May 2019 09:59:09 -0400 [thread overview]
Message-ID: <20190516095618-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <9f6b1d8e-ef90-7d8b-56da-61a426953ba3@redhat.com>
On Wed, May 15, 2019 at 10:46:00PM +0200, David Hildenbrand wrote:
> > + vpmem->vdev = vdev;
> > + vdev->priv = vpmem;
> > + err = init_vq(vpmem);
> > + if (err) {
> > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n");
> > + goto out_err;
> > + }
> > +
> > + 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;
>
> nit: " - 1;"
>
> > + vpmem->nd_desc.provider_name = "virtio-pmem";
> > + vpmem->nd_desc.module = THIS_MODULE;
> > +
> > + vpmem->nvdimm_bus = nvdimm_bus_register(&vdev->dev,
> > + &vpmem->nd_desc);
> > + if (!vpmem->nvdimm_bus) {
> > + dev_err(&vdev->dev, "failed to register device with nvdimm_bus\n");
> > + err = -ENXIO;
> > + goto out_vq;
> > + }
> > +
> > + dev_set_drvdata(&vdev->dev, vpmem->nvdimm_bus);
> > +
> > + ndr_desc.res = &res;
> > + ndr_desc.numa_node = nid;
> > + ndr_desc.flush = async_pmem_flush;
> > + set_bit(ND_REGION_PAGEMAP, &ndr_desc.flags);
> > + set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
> > + nd_region = nvdimm_pmem_region_create(vpmem->nvdimm_bus, &ndr_desc);
> > + if (!nd_region) {
> > + dev_err(&vdev->dev, "failed to create nvdimm region\n");
> > + err = -ENXIO;
> > + goto out_nd;
> > + }
> > + nd_region->provider_data = dev_to_virtio(nd_region->dev.parent->parent);
> > + return 0;
> > +out_nd:
> > + nvdimm_bus_unregister(vpmem->nvdimm_bus);
> > +out_vq:
> > + vdev->config->del_vqs(vdev);
> > +out_err:
> > + 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);
> > + vdev->config->reset(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/drivers/nvdimm/virtio_pmem.h b/drivers/nvdimm/virtio_pmem.h
> > new file mode 100644
> > index 000000000000..ab1da877575d
> > --- /dev/null
> > +++ b/drivers/nvdimm/virtio_pmem.h
> > @@ -0,0 +1,60 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * virtio_pmem.h: virtio pmem Driver
> > + *
> > + * Discovers persistent memory range information
> > + * from host and provides a virtio based flushing
> > + * interface.
> > + **/
> > +
> > +#ifndef _LINUX_VIRTIO_PMEM_H
> > +#define _LINUX_VIRTIO_PMEM_H
> > +
> > +#include <linux/virtio_ids.h>
> > +#include <linux/module.h>
> > +#include <linux/virtio_config.h>
> > +#include <uapi/linux/virtio_pmem.h>
> > +#include <linux/libnvdimm.h>
> > +#include <linux/spinlock.h>
> > +
> > +struct virtio_pmem_request {
> > + /* Host return status corresponding to flush request */
> > + int ret;
> > +
> > + /* command name*/
> > + char name[16];
>
> So ... why are we sending string commands and expect native-endianess
> integers and don't define a proper request/response structure + request
> types in include/uapi/linux/virtio_pmem.h like
passing names could be ok.
I missed the fact we return a native endian int.
Pls fix that.
>
> struct virtio_pmem_resp {
> __virtio32 ret;
> }
>
> #define VIRTIO_PMEM_REQ_TYPE_FLUSH 1
> struct virtio_pmem_req {
> __virtio16 type;
> }
>
> ... and this way we also define a proper endianess format for exchange
> and keep it extensible
>
> @MST, what's your take on this?
Extensions can always use feature bits so I don't think
it's a problem.
>
> --
>
> Thanks,
>
> David / dhildenb
next prev parent reply other threads:[~2019-05-16 13:59 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 14:54 [PATCH v9 0/7] virtio pmem driver Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 1/7] libnvdimm: nd_region flush callback support Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-15 21:07 ` Dan Williams
2019-05-15 21:07 ` Dan Williams
2019-05-15 21:07 ` [Qemu-devel] " Dan Williams
2019-05-15 21:07 ` Dan Williams
2019-05-16 6:28 ` Pankaj Gupta
2019-05-16 6:28 ` [Qemu-devel] " Pankaj Gupta
2019-05-16 6:28 ` Pankaj Gupta
2019-05-16 6:28 ` Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 15:09 ` Randy Dunlap
2019-05-14 15:09 ` [Qemu-devel] " Randy Dunlap
2019-05-14 15:09 ` Randy Dunlap
2019-05-14 15:25 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 15:25 ` Pankaj Gupta
2019-05-14 15:25 ` Pankaj Gupta
2019-05-14 15:25 ` Pankaj Gupta
2019-05-14 15:25 ` Pankaj Gupta
2019-05-15 20:46 ` Dan Williams
2019-05-15 20:46 ` Dan Williams
2019-05-15 20:46 ` Dan Williams
2019-05-15 20:46 ` Dan Williams
2019-05-15 20:46 ` David Hildenbrand
2019-05-15 20:46 ` [Qemu-devel] " David Hildenbrand
2019-05-15 20:46 ` David Hildenbrand
2019-05-15 20:52 ` David Hildenbrand
2019-05-15 20:52 ` David Hildenbrand
2019-05-15 20:52 ` [Qemu-devel] " David Hildenbrand
2019-05-16 7:54 ` Pankaj Gupta
2019-05-16 7:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-16 7:54 ` Pankaj Gupta
2019-05-16 7:54 ` Pankaj Gupta
2019-05-16 7:49 ` Pankaj Gupta
2019-05-16 7:49 ` [Qemu-devel] " Pankaj Gupta
2019-05-16 7:49 ` Pankaj Gupta
2019-05-16 7:49 ` Pankaj Gupta
2019-05-16 13:59 ` Michael S. Tsirkin
2019-05-16 13:59 ` Michael S. Tsirkin [this message]
2019-05-16 13:59 ` [Qemu-devel] " Michael S. Tsirkin
2019-05-16 13:59 ` Michael S. Tsirkin
2019-05-17 5:31 ` [Qemu-devel] " Pankaj Gupta
2019-05-17 5:31 ` Pankaj Gupta
2019-05-17 5:31 ` Pankaj Gupta
2019-05-17 5:31 ` Pankaj Gupta
2019-05-17 0:12 ` Jakub Staroń via Virtualization
2019-05-17 0:12 ` Jakub Staroń
2019-05-17 0:12 ` [Qemu-devel] " Jakub Staroń via Qemu-devel
2019-05-17 0:12 ` Jakub Staroń
2019-05-17 5:35 ` [Qemu-devel] " Pankaj Gupta
2019-05-17 5:35 ` Pankaj Gupta
2019-05-17 5:35 ` Pankaj Gupta
2019-05-18 1:10 ` Jakub Staroń via Virtualization
2019-05-18 1:10 ` Jakub Staroń
2019-05-18 1:10 ` Jakub Staroń via Qemu-devel
2019-05-18 1:10 ` Jakub Staroń
2019-05-20 3:46 ` Pankaj Gupta
2019-05-20 3:46 ` Pankaj Gupta
2019-05-20 3:46 ` Pankaj Gupta
2019-05-20 3:46 ` Pankaj Gupta
2019-05-20 3:47 ` Pankaj Gupta
2019-05-20 3:47 ` Pankaj Gupta
2019-05-20 3:47 ` Pankaj Gupta
2019-05-20 3:47 ` Pankaj Gupta
2019-05-17 5:35 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 3/7] libnvdimm: add dax_dev sync flag Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 4/7] dm: enable synchronous dax Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-15 20:48 ` Dan Williams
2019-05-15 20:48 ` Dan Williams
2019-05-15 20:48 ` [Qemu-devel] " Dan Williams
2019-05-15 20:48 ` Dan Williams
2019-05-15 20:48 ` Dan Williams
2019-05-14 14:54 ` [PATCH v9 5/7] dax: check synchronous mapping is supported Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 6/7] ext4: disable map_sync for async flush Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` [PATCH v9 7/7] xfs: " Pankaj Gupta
2019-05-14 14:54 ` [Qemu-devel] " Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
2019-05-14 14:54 ` Pankaj Gupta
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=20190516095618-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aarcange@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=cohuck@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=dave.jiang@intel.com \
--cc=david@fromorbit.com \
--cc=david@redhat.com \
--cc=hch@infradead.org \
--cc=imammedo@redhat.com \
--cc=jack@suse.cz \
--cc=jasowang@redhat.com \
--cc=jmoyer@redhat.com \
--cc=jstaron@google.com \
--cc=kilobyte@angband.pl \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nilal@redhat.com \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=riel@surriel.com \
--cc=rjw@rjwysocki.net \
--cc=stefanha@redhat.com \
--cc=tytso@mit.edu \
--cc=virtualization@lists.linux-foundation.org \
--cc=vishal.l.verma@intel.com \
--cc=willy@infradead.org \
--cc=xiaoguangrong.eric@gmail.com \
--cc=yuval.shaia@oracle.com \
--cc=zwisler@kernel.org \
/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.