Re: [PATCH v2] virtio_pmem: fix sparse warning
>
> On Wed, Jul 10, 2019 at 11:28:32PM +0530, Pankaj Gupta wrote:
> > This patch fixes below sparse warning related to __virtio
> > type in virtio pmem driver. This is reported by Intel test
> > bot on linux-next tree.
> >
> > nd_virtio.c:56:28: warning: incorrect type in assignment
> > (different base types)
> > nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
> > nd_virtio.c:56:28:got restricted __virtio32
> > nd_virtio.c:93:59: warning: incorrect type in argument 2
> > (different base types)
> > nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
> > nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
> >
> > Reported-by: kbuild test robot
> > Signed-off-by: Pankaj Gupta
> > ---
> >
> > This fixes a warning, so submitting it as a separate
> > patch on top of virtio pmem series.
> >
> > include/uapi/linux/virtio_pmem.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/uapi/linux/virtio_pmem.h
> > b/include/uapi/linux/virtio_pmem.h
> > index efcd72f2d20d..7a7435281362 100644
> > --- a/include/uapi/linux/virtio_pmem.h
> > +++ b/include/uapi/linux/virtio_pmem.h
> > @@ -10,7 +10,7 @@
> > #ifndef _UAPI_LINUX_VIRTIO_PMEM_H
> > #define _UAPI_LINUX_VIRTIO_PMEM_H
> >
> > -#include
> > +#include
> > #include
> > #include
> >
> > @@ -23,12 +23,12 @@ struct virtio_pmem_config {
> >
> > struct virtio_pmem_resp {
> > /* Host return status corresponding to flush request */
> > - __u32 ret;
> > + __virtio32 ret;
> > };
> >
> > struct virtio_pmem_req {
> > /* command type */
> > - __u32 type;
> > + __virtio32 type;
> > };
> >
> > #endif
>
> Same comment as previously: pls use __le and fix accessors.
Now, I think I got it.
__virtio is for legacy devices to solve the endianess.
By default virtio 1.0 and later are little endian.
Will send updated patch soon.
Thank you,
Pankaj
>
> > --
> > 2.20.1
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_pmem: fix sparse warning
>
> On Wed, Jul 10, 2019 at 07:57:00PM +0530, Pankaj Gupta wrote:
> > This patch fixes below sparse warning related to __virtio
> > type in virtio pmem driver. This is reported by Intel test
> > bot on linux-next tree.
> >
> > nd_virtio.c:56:28: warning: incorrect type in assignment (different base
> > types)
> > nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
> > nd_virtio.c:56:28:got restricted __virtio32
> > nd_virtio.c:93:59: warning: incorrect type in argument 2 (different base
> > types)
> > nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
> > nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
> >
> > Signed-off-by: Pankaj Gupta
> > Reported-by: kbuild test robot
> > ---
> >
> > This fixes a warning, so submitting it as a separate
> > patch on top of virtio pmem series.
> >
> > include/uapi/linux/virtio_pmem.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/uapi/linux/virtio_pmem.h
> > b/include/uapi/linux/virtio_pmem.h
> > index efcd72f2d20d..f89129bf1f84 100644
> > --- a/include/uapi/linux/virtio_pmem.h
> > +++ b/include/uapi/linux/virtio_pmem.h
> > @@ -23,12 +23,12 @@ struct virtio_pmem_config {
> >
> > struct virtio_pmem_resp {
> > /* Host return status corresponding to flush request */
> > - __u32 ret;
> > + __virtio32 ret;
> > };
> >
> > struct virtio_pmem_req {
> > /* command type */
> > - __u32 type;
> > + __virtio32 type;
> > };
> >
> > #endif
>
> req/resp are in memory right?
> Then this looks like a wrong fix.
> The accessors should all use cpu_to/from_le
> and they types should be __le32.
o.k
>
> > --
> > 2.20.1
>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On Thu, Jul 11, 2019 at 01:41:34PM +0200, Stefano Garzarella wrote: > On Thu, Jul 11, 2019 at 03:37:00PM +0800, Jason Wang wrote: > > > > On 2019/7/10 下午11:37, Stefano Garzarella wrote: > > > Hi, > > > as Jason suggested some months ago, I looked better at the virtio-net > > > driver to > > > understand if we can reuse some parts also in the virtio-vsock driver, > > > since we > > > have similar challenges (mergeable buffers, page allocation, small > > > packets, etc.). > > > > > > Initially, I would add the skbuff in the virtio-vsock in order to re-use > > > receive_*() functions. > > > > > > Yes, that will be a good step. > > > > Okay, I'll go on this way. > > > > > > Then I would move receive_[small, big, mergeable]() and > > > add_recvbuf_[small, big, mergeable]() outside of virtio-net driver, in > > > order to > > > call them also from virtio-vsock. I need to do some refactoring (e.g. > > > leave the > > > XDP part on the virtio-net driver), but I think it is feasible. > > > > > > The idea is to create a virtio-skb.[h,c] where put these functions and a > > > new > > > object where stores some attributes needed (e.g. hdr_len ) and status > > > (e.g. > > > some fields of struct receive_queue). > > > > > > My understanding is we could be more ambitious here. Do you see any blocker > > for reusing virtio-net directly? It's better to reuse not only the functions > > but also the logic like NAPI to avoid re-inventing something buggy and > > duplicated. > > > > These are my concerns: > - virtio-vsock is not a "net_device", so a lot of code related to > ethtool, net devices (MAC address, MTU, speed, VLAN, XDP, offloading) will > be > not used by virtio-vsock. > > - virtio-vsock has a different header. We can consider it as part of > virtio_net payload, but it precludes the compatibility with old hosts. This > was one of the major doubts that made me think about using only the > send/recv skbuff functions, that it shouldn't break the compatibility. > > > > > > This is an idea of virtio-skb.h that > > > I have in mind: > > > struct virtskb; > > > > > > What fields do you want to store in virtskb? It looks to be exist sk_buff is > > flexible enough to us? > > My idea is to store queues information, like struct receive_queue or > struct send_queue, and some device attributes (e.g. hdr_len ). > > > > > > > > > > > struct sk_buff *virtskb_receive_small(struct virtskb *vs, ...); > > > struct sk_buff *virtskb_receive_big(struct virtskb *vs, ...); > > > struct sk_buff *virtskb_receive_mergeable(struct virtskb *vs, ...); > > > > > > int virtskb_add_recvbuf_small(struct virtskb*vs, ...); > > > int virtskb_add_recvbuf_big(struct virtskb *vs, ...); > > > int virtskb_add_recvbuf_mergeable(struct virtskb *vs, ...); > > > > > > For the Guest->Host path it should be easier, so maybe I can add a > > > "virtskb_send(struct virtskb *vs, struct sk_buff *skb)" with a part of > > > the code > > > of xmit_skb(). > > > > > > I may miss something, but I don't see any thing that prevents us from using > > xmit_skb() directly. > > > > Yes, but my initial idea was to make it more parametric and not related to the > virtio_net_hdr, so the 'hdr_len' could be a parameter and the > 'num_buffers' should be handled by the caller. > > > > > > > > > Let me know if you have in mind better names or if I should put these > > > function > > > in another place. > > > > > > I would like to leave the control part completely separate, so, for > > > example, > > > the two drivers will negotiate the features independently and they will > > > call > > > the right virtskb_receive_*() function based on the negotiation. > > > > > > If it's one the issue of negotiation, we can simply change the > > virtnet_probe() to deal with different devices. > > > > > > > > > > I already started to work on it, but before to do more steps and send an > > > RFC > > > patch, I would like to hear your opinion. > > > Do you think that makes sense? > > > Do you see any issue or a better solution? > > > > > > I still think we need to seek a way of adding some codes on virtio-net.c > > directly if there's no huge different in the processing of TX/RX. That would > > save us a lot time. > > After the reading of the buffers from the virtqueue I think the process > is slightly different, because virtio-net will interface with the network > stack, while virtio-vsock will interface with the vsock-core (socket). > So the virtio-vsock implements the following: > - control flow mechanism to avoid to loose packets, informing the peer > about the amount of memory available in the receive queue using some > fields in the virtio_vsock_hdr > - de-multiplexing parsing the virtio_vsock_hdr and choosing the right > socket depending on the port > - socket state handling > > We can use the virtio-net as transport, but we should add a lot of > code to skip "net device" stuff when it is used by
Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On 2019/7/10 下午11:37, Stefano Garzarella wrote: Hi, as Jason suggested some months ago, I looked better at the virtio-net driver to understand if we can reuse some parts also in the virtio-vsock driver, since we have similar challenges (mergeable buffers, page allocation, small packets, etc.). Initially, I would add the skbuff in the virtio-vsock in order to re-use receive_*() functions. Yes, that will be a good step. Then I would move receive_[small, big, mergeable]() and add_recvbuf_[small, big, mergeable]() outside of virtio-net driver, in order to call them also from virtio-vsock. I need to do some refactoring (e.g. leave the XDP part on the virtio-net driver), but I think it is feasible. The idea is to create a virtio-skb.[h,c] where put these functions and a new object where stores some attributes needed (e.g. hdr_len ) and status (e.g. some fields of struct receive_queue). My understanding is we could be more ambitious here. Do you see any blocker for reusing virtio-net directly? It's better to reuse not only the functions but also the logic like NAPI to avoid re-inventing something buggy and duplicated. This is an idea of virtio-skb.h that I have in mind: struct virtskb; What fields do you want to store in virtskb? It looks to be exist sk_buff is flexible enough to us? struct sk_buff *virtskb_receive_small(struct virtskb *vs, ...); struct sk_buff *virtskb_receive_big(struct virtskb *vs, ...); struct sk_buff *virtskb_receive_mergeable(struct virtskb *vs, ...); int virtskb_add_recvbuf_small(struct virtskb*vs, ...); int virtskb_add_recvbuf_big(struct virtskb *vs, ...); int virtskb_add_recvbuf_mergeable(struct virtskb *vs, ...); For the Guest->Host path it should be easier, so maybe I can add a "virtskb_send(struct virtskb *vs, struct sk_buff *skb)" with a part of the code of xmit_skb(). I may miss something, but I don't see any thing that prevents us from using xmit_skb() directly. Let me know if you have in mind better names or if I should put these function in another place. I would like to leave the control part completely separate, so, for example, the two drivers will negotiate the features independently and they will call the right virtskb_receive_*() function based on the negotiation. If it's one the issue of negotiation, we can simply change the virtnet_probe() to deal with different devices. I already started to work on it, but before to do more steps and send an RFC patch, I would like to hear your opinion. Do you think that makes sense? Do you see any issue or a better solution? I still think we need to seek a way of adding some codes on virtio-net.c directly if there's no huge different in the processing of TX/RX. That would save us a lot time. Thanks Thanks in advance, Stefano ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock
On Thu, Jul 11, 2019 at 03:37:00PM +0800, Jason Wang wrote: > > On 2019/7/10 下午11:37, Stefano Garzarella wrote: > > Hi, > > as Jason suggested some months ago, I looked better at the virtio-net > > driver to > > understand if we can reuse some parts also in the virtio-vsock driver, > > since we > > have similar challenges (mergeable buffers, page allocation, small > > packets, etc.). > > > > Initially, I would add the skbuff in the virtio-vsock in order to re-use > > receive_*() functions. > > > Yes, that will be a good step. > Okay, I'll go on this way. > > > Then I would move receive_[small, big, mergeable]() and > > add_recvbuf_[small, big, mergeable]() outside of virtio-net driver, in > > order to > > call them also from virtio-vsock. I need to do some refactoring (e.g. leave > > the > > XDP part on the virtio-net driver), but I think it is feasible. > > > > The idea is to create a virtio-skb.[h,c] where put these functions and a new > > object where stores some attributes needed (e.g. hdr_len ) and status (e.g. > > some fields of struct receive_queue). > > > My understanding is we could be more ambitious here. Do you see any blocker > for reusing virtio-net directly? It's better to reuse not only the functions > but also the logic like NAPI to avoid re-inventing something buggy and > duplicated. > These are my concerns: - virtio-vsock is not a "net_device", so a lot of code related to ethtool, net devices (MAC address, MTU, speed, VLAN, XDP, offloading) will be not used by virtio-vsock. - virtio-vsock has a different header. We can consider it as part of virtio_net payload, but it precludes the compatibility with old hosts. This was one of the major doubts that made me think about using only the send/recv skbuff functions, that it shouldn't break the compatibility. > > > This is an idea of virtio-skb.h that > > I have in mind: > > struct virtskb; > > > What fields do you want to store in virtskb? It looks to be exist sk_buff is > flexible enough to us? My idea is to store queues information, like struct receive_queue or struct send_queue, and some device attributes (e.g. hdr_len ). > > > > > > struct sk_buff *virtskb_receive_small(struct virtskb *vs, ...); > > struct sk_buff *virtskb_receive_big(struct virtskb *vs, ...); > > struct sk_buff *virtskb_receive_mergeable(struct virtskb *vs, ...); > > > > int virtskb_add_recvbuf_small(struct virtskb*vs, ...); > > int virtskb_add_recvbuf_big(struct virtskb *vs, ...); > > int virtskb_add_recvbuf_mergeable(struct virtskb *vs, ...); > > > > For the Guest->Host path it should be easier, so maybe I can add a > > "virtskb_send(struct virtskb *vs, struct sk_buff *skb)" with a part of the > > code > > of xmit_skb(). > > > I may miss something, but I don't see any thing that prevents us from using > xmit_skb() directly. > Yes, but my initial idea was to make it more parametric and not related to the virtio_net_hdr, so the 'hdr_len' could be a parameter and the 'num_buffers' should be handled by the caller. > > > > > Let me know if you have in mind better names or if I should put these > > function > > in another place. > > > > I would like to leave the control part completely separate, so, for example, > > the two drivers will negotiate the features independently and they will call > > the right virtskb_receive_*() function based on the negotiation. > > > If it's one the issue of negotiation, we can simply change the > virtnet_probe() to deal with different devices. > > > > > > I already started to work on it, but before to do more steps and send an RFC > > patch, I would like to hear your opinion. > > Do you think that makes sense? > > Do you see any issue or a better solution? > > > I still think we need to seek a way of adding some codes on virtio-net.c > directly if there's no huge different in the processing of TX/RX. That would > save us a lot time. After the reading of the buffers from the virtqueue I think the process is slightly different, because virtio-net will interface with the network stack, while virtio-vsock will interface with the vsock-core (socket). So the virtio-vsock implements the following: - control flow mechanism to avoid to loose packets, informing the peer about the amount of memory available in the receive queue using some fields in the virtio_vsock_hdr - de-multiplexing parsing the virtio_vsock_hdr and choosing the right socket depending on the port - socket state handling We can use the virtio-net as transport, but we should add a lot of code to skip "net device" stuff when it is used by the virtio-vsock. This could break something in virtio-net, for this reason, I thought to reuse only the send/recv functions starting from the idea to split the virtio-net driver in two parts: a. one with all stuff related to the network stack b. one with the stuff needed to communicate with the host And use skbuff to communicate between parts. In this
Re: [PATCH] virtio_pmem: fix sparse warning
On Wed, Jul 10, 2019 at 07:57:00PM +0530, Pankaj Gupta wrote:
> This patch fixes below sparse warning related to __virtio
> type in virtio pmem driver. This is reported by Intel test
> bot on linux-next tree.
>
> nd_virtio.c:56:28: warning: incorrect type in assignment (different base
> types)
> nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
> nd_virtio.c:56:28:got restricted __virtio32
> nd_virtio.c:93:59: warning: incorrect type in argument 2 (different base
> types)
> nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
> nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
>
> Signed-off-by: Pankaj Gupta
> Reported-by: kbuild test robot
> ---
>
> This fixes a warning, so submitting it as a separate
> patch on top of virtio pmem series.
>
> include/uapi/linux/virtio_pmem.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/virtio_pmem.h
> b/include/uapi/linux/virtio_pmem.h
> index efcd72f2d20d..f89129bf1f84 100644
> --- a/include/uapi/linux/virtio_pmem.h
> +++ b/include/uapi/linux/virtio_pmem.h
> @@ -23,12 +23,12 @@ struct virtio_pmem_config {
>
> struct virtio_pmem_resp {
> /* Host return status corresponding to flush request */
> - __u32 ret;
> + __virtio32 ret;
> };
>
> struct virtio_pmem_req {
> /* command type */
> - __u32 type;
> + __virtio32 type;
> };
>
> #endif
req/resp are in memory right?
Then this looks like a wrong fix.
The accessors should all use cpu_to/from_le
and they types should be __le32.
> --
> 2.20.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] virtio_pmem: fix sparse warning
On Wed, Jul 10, 2019 at 11:28:32PM +0530, Pankaj Gupta wrote:
> This patch fixes below sparse warning related to __virtio
> type in virtio pmem driver. This is reported by Intel test
> bot on linux-next tree.
>
> nd_virtio.c:56:28: warning: incorrect type in assignment
> (different base types)
> nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
> nd_virtio.c:56:28:got restricted __virtio32
> nd_virtio.c:93:59: warning: incorrect type in argument 2
> (different base types)
> nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
> nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
>
> Reported-by: kbuild test robot
> Signed-off-by: Pankaj Gupta
> ---
>
> This fixes a warning, so submitting it as a separate
> patch on top of virtio pmem series.
>
> include/uapi/linux/virtio_pmem.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/virtio_pmem.h
> b/include/uapi/linux/virtio_pmem.h
> index efcd72f2d20d..7a7435281362 100644
> --- a/include/uapi/linux/virtio_pmem.h
> +++ b/include/uapi/linux/virtio_pmem.h
> @@ -10,7 +10,7 @@
> #ifndef _UAPI_LINUX_VIRTIO_PMEM_H
> #define _UAPI_LINUX_VIRTIO_PMEM_H
>
> -#include
> +#include
> #include
> #include
>
> @@ -23,12 +23,12 @@ struct virtio_pmem_config {
>
> struct virtio_pmem_resp {
> /* Host return status corresponding to flush request */
> - __u32 ret;
> + __virtio32 ret;
> };
>
> struct virtio_pmem_req {
> /* command type */
> - __u32 type;
> + __virtio32 type;
> };
>
> #endif
Same comment as previously: pls use __le and fix accessors.
> --
> 2.20.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v5 1/8] s390/mm: force swiotlb for protected virtualization
Hello Halil, Halil Pasic writes: > On s390, protected virtualization guests have to use bounced I/O > buffers. That requires some plumbing. > > Let us make sure, any device that uses DMA API with direct ops correctly > is spared from the problems, that a hypervisor attempting I/O to a > non-shared page would bring. > > Signed-off-by: Halil Pasic > Reviewed-by: Claudio Imbrenda > --- > arch/s390/Kconfig | 4 +++ > arch/s390/include/asm/mem_encrypt.h | 18 +++ > arch/s390/mm/init.c | 47 + > 3 files changed, 69 insertions(+) > create mode 100644 arch/s390/include/asm/mem_encrypt.h > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index 109243fdb6ec..88d8355b7bf7 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -1,4 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > +config ARCH_HAS_MEM_ENCRYPT > +def_bool y > + > config MMU > def_bool y > ARCH_HAS_MEM_ENCRYPT is already defined in arch/Kconfig, so I think you can just select it in config S390 like you do with SWIOTLB. > @@ -187,6 +190,7 @@ config S390 > select VIRT_CPU_ACCOUNTING > select ARCH_HAS_SCALED_CPUTIME > select HAVE_NMI > + select SWIOTLB > > > config SCHED_OMIT_FRAME_POINTER -- Thiago Jung Bauermann IBM Linux Technology Center ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] scsi: virtio_scsi: Use struct_size() helper
Gustavo, > One of the more common cases of allocation size calculations is finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3] virtio_pmem: fix sparse warning
This patch fixes below sparse warning related to __virtio
type in virtio pmem driver. This is reported by Intel test
bot on linux-next tree.
nd_virtio.c:56:28: warning: incorrect type in assignment
(different base types)
nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
nd_virtio.c:56:28:got restricted __virtio32
nd_virtio.c:93:59: warning: incorrect type in argument 2
(different base types)
nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
Reported-by: kbuild test robot
Signed-off-by: Pankaj Gupta
---
This fixes a warning, so submitting it as a separate
patch on top of virtio pmem series.
v2-> v3
Use __le for req/resp fields - Michael
drivers/nvdimm/nd_virtio.c | 4 ++--
include/uapi/linux/virtio_pmem.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
index 8645275c08c2..10351d5b49fa 100644
--- a/drivers/nvdimm/nd_virtio.c
+++ b/drivers/nvdimm/nd_virtio.c
@@ -53,7 +53,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
init_waitqueue_head(_data->host_acked);
init_waitqueue_head(_data->wq_buf);
INIT_LIST_HEAD(_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(, _data->req, sizeof(req_data->req));
sgs[0] =
sg_init_one(, _data->resp.ret, sizeof(req_data->resp));
@@ -90,7 +90,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
} else {
/* A host repsonse results in "host_ack" getting called */
wait_event(req_data->host_acked, req_data->done);
- err = virtio32_to_cpu(vdev, req_data->resp.ret);
+ err = le32_to_cpu(req_data->resp.ret);
}
kfree(req_data);
diff --git a/include/uapi/linux/virtio_pmem.h b/include/uapi/linux/virtio_pmem.h
index efcd72f2d20d..9a63ed6d062f 100644
--- a/include/uapi/linux/virtio_pmem.h
+++ b/include/uapi/linux/virtio_pmem.h
@@ -23,12 +23,12 @@ struct virtio_pmem_config {
struct virtio_pmem_resp {
/* Host return status corresponding to flush request */
- __u32 ret;
+ __le32 ret;
};
struct virtio_pmem_req {
/* command type */
- __u32 type;
+ __le32 type;
};
#endif
--
2.14.5
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
