[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
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
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: [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: [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: [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: [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: [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