search for: virtio_pmem_req_type_flush

...++ b/drivers/nvdimm/nd_virtio.c @@ -53,7 +53,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region) init_waitqueue_head(&req_data->host_acked); init_waitqueue_head(&req_data->wq_buf); INIT_LIST_HEAD(&req_data->list); - req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); + req_data->req.type = cpu_to_le32(VIRTIO_PMEM_REQ_TYPE_FLUSH); sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); sgs[0] = &sg; sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); @@ -90,7 +90,7 @@ static int virtio_pmem_flush(struct nd_...

...++ b/drivers/nvdimm/nd_virtio.c @@ -53,7 +53,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region) init_waitqueue_head(&req_data->host_acked); init_waitqueue_head(&req_data->wq_buf); INIT_LIST_HEAD(&req_data->list); - req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); + req_data->req.type = cpu_to_le32(VIRTIO_PMEM_REQ_TYPE_FLUSH); sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); sgs[0] = &sg; sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); @@ -90,7 +90,7 @@ static int virtio_pmem_flush(struct nd_...

...; + > + /* 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 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? -- Thanks, David / dhildenb

...; + > + /* 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 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? -- Thanks, David / dhildenb

...linux/virtio_types.h> > +#include <linux/virtio_ids.h> > +#include <linux/virtio_config.h> > + > +struct virtio_pmem_config { > + __le64 start; > + __le64 size; > +}; > + config generally should be __u64. Are you sure sparse does not complain? > +#define VIRTIO_PMEM_REQ_TYPE_FLUSH 0 > + > +struct virtio_pmem_resp { > + /* Host return status corresponding to flush request */ > + __virtio32 ret; > +}; > + > +struct virtio_pmem_req { > + /* command type */ > + __virtio32 type; > +}; > + > +#endif > -- > 2.20.1 Sorry why are these...

...rtio.c > @@ -53,7 +53,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region) > init_waitqueue_head(&req_data->host_acked); > init_waitqueue_head(&req_data->wq_buf); > INIT_LIST_HEAD(&req_data->list); > - req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); > + req_data->req.type = cpu_to_le32(VIRTIO_PMEM_REQ_TYPE_FLUSH); > sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); > sgs[0] = &sg; > sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); > @@ -90,7 +90,7 @@ static int vir...

...kmalloc(sizeof(*req_data), GFP_KERNEL); + if (!req_data) + return -ENOMEM; + + req_data->done = false; + init_waitqueue_head(&req_data->host_acked); + init_waitqueue_head(&req_data->wq_buf); + INIT_LIST_HEAD(&req_data->list); + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); + sgs[0] = &sg; + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); + sgs[1] = &ret; + + spin_lock_irqsave(&vpmem->pmem_lock, flags); + /* + * If virtqueue_add_sgs returns -ENOSP...

...kmalloc(sizeof(*req_data), GFP_KERNEL); + if (!req_data) + return -ENOMEM; + + req_data->done = false; + init_waitqueue_head(&req_data->host_acked); + init_waitqueue_head(&req_data->wq_buf); + INIT_LIST_HEAD(&req_data->list); + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); + sgs[0] = &sg; + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); + sgs[1] = &ret; + + spin_lock_irqsave(&vpmem->pmem_lock, flags); + /* + * If virtqueue_add_sgs returns -ENOSP...

...kmalloc(sizeof(*req_data), GFP_KERNEL); + if (!req_data) + return -ENOMEM; + + req_data->done = false; + init_waitqueue_head(&req_data->host_acked); + init_waitqueue_head(&req_data->wq_buf); + INIT_LIST_HEAD(&req_data->list); + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); + sgs[0] = &sg; + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); + sgs[1] = &ret; + + spin_lock_irqsave(&vpmem->pmem_lock, flags); + /* + * If virtqueue_add_sgs returns -ENOSP...

...nux/virtio_pmem.h index b022787ffb94..d676b3620383 100644 --- a/include/uapi/linux/virtio_pmem.h +++ b/include/uapi/linux/virtio_pmem.h @@ -15,8 +15,8 @@ #include <linux/virtio_config.h> struct virtio_pmem_config { - __u64 start; - __u64 size; + __le64 start; + __le64 size; }; #define VIRTIO_PMEM_REQ_TYPE_FLUSH 0 -- MST

...nux/virtio_pmem.h index b022787ffb94..d676b3620383 100644 --- a/include/uapi/linux/virtio_pmem.h +++ b/include/uapi/linux/virtio_pmem.h @@ -15,8 +15,8 @@ #include <linux/virtio_config.h> struct virtio_pmem_config { - __u64 start; - __u64 size; + __le64 start; + __le64 size; }; #define VIRTIO_PMEM_REQ_TYPE_FLUSH 0 -- MST

...re + request > types in include/uapi/linux/virtio_pmem.h like > > struct virtio_pmem_resp { > __virtio32 ret; > } FWIW, I wonder if we should even properly translate return values and define types like VIRTIO_PMEM_RESP_TYPE_OK 0 VIRTIO_PMEM_RESP_TYPE_EIO 1 .. > > #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? > > -- Thanks, David / dhildenb

...rs 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....

...> + if (!req_data) > + return -ENOMEM; > + > + req_data->done = false; > + init_waitqueue_head(&req_data->host_acked); > + init_waitqueue_head(&req_data->wq_buf); > + INIT_LIST_HEAD(&req_data->list); > + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); > + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); > + sgs[0] = &sg; > + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); > + sgs[1] = &ret; > + > + spin_lock_irqsave(&vpmem->pmem_lock, flags); > + /* > +...

...> + if (!req_data) > + return -ENOMEM; > + > + req_data->done = false; > + init_waitqueue_head(&req_data->host_acked); > + init_waitqueue_head(&req_data->wq_buf); > + INIT_LIST_HEAD(&req_data->list); > + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); > + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); > + sgs[0] = &sg; > + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); > + sgs[1] = &ret; > + > + spin_lock_irqsave(&vpmem->pmem_lock, flags); > + /* > +...

...return -ENOMEM; > > + > > + req_data->done = false; > > + init_waitqueue_head(&req_data->host_acked); > > + init_waitqueue_head(&req_data->wq_buf); > > + INIT_LIST_HEAD(&req_data->list); > > + req_data->req.type = cpu_to_virtio32(vdev, VIRTIO_PMEM_REQ_TYPE_FLUSH); > > + sg_init_one(&sg, &req_data->req, sizeof(req_data->req)); > > + sgs[0] = &sg; > > + sg_init_one(&ret, &req_data->resp.ret, sizeof(req_data->resp)); > > + sgs[1] = &ret; > > + > > + spin_lock_irqsave(&vpmem->pmem_l...

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 & VIRTIO patches. Need an ack on device mapper change in patch 4. Mike, Can you please review patch 4 which has change for dax with device mapper. Incorporated all the changes suggested in v9. This version has minor changes in patch 2(virtio) and does not change the

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 & VIRTIO patches. Device mapper change is also reviewed. Mike, Can you please provide ack for device mapper change i.e patch4. This version has changed implementation for patch 4 as suggested by 'Mike'. Keeping all the existing r-o-bs. Jakob CCed also tested the

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 & VIRTIO patches. Need an ack on device mapper change in patch 4. Mike, Can you please review and ack patch4. This version does not has any additonal code change from v10 and is only rebase of v10 on Linux 5.2-rc4 which is required for patch4. Keeping all the existing

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 device mapper & VIRTIO patches. This version has fix for test bot build failure. Keeping all the existing r-o-bs. Jakob CCed also tested the patch series and confirmed the working of v9. --- This patch series has implementation for "virtio pmem". "virtio