Re: [PATCH net-next 1/2] virtio_net: Fix short frame length check
On Fri, Jan 13, 2023 at 4:23 PM Alexander Duyck
wrote:
>
> On Fri, Jan 13, 2023 at 3:37 PM Parav Pandit wrote:
> >
> >
> > > From: Alexander H Duyck
> > > Sent: Friday, January 13, 2023 6:24 PM
> > >
> > > On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > > > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > > > any preemble and CRC.
> > > >
> > > > Current code only checks for minimal 14 bytes of Ethernet header length.
> > > > Correct it to consider the minimum Ethernet frame length.
> > > >
> > > > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > > > Signed-off-by: Parav Pandit
> > > > ---
> > > > drivers/net/virtio_net.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > > > 7723b2a49d8e..d45e140b6852 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi,
> > > struct receive_queue *rq,
> > > > struct sk_buff *skb;
> > > > struct virtio_net_hdr_mrg_rxbuf *hdr;
> > > >
> > > > - if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > > > + if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> > > > pr_debug("%s: short packet %i\n", dev->name, len);
> > > > dev->stats.rx_length_errors++;
> > > > if (vi->mergeable_rx_bufs) {
> > >
> > > I'm not sure I agree with this change as packets are only 60B if they
> > > have gone
> > > across the wire as they are usually padded out on the transmit side.
> > > There may
> > > be cases where software routed packets may not be 60B.
> > >
> > Do you mean Linux kernel software? Any link to it would be helpful.
>
> The problem is there are several software paths involved and that is
> why I am wanting to be cautious. As I recall this would impact Qemu
> itself, DPDK, the Linux Kernel and several others if I am not
> mistaken. That is why I am tending to err on the side of caution as
> this is a pretty significant change.
>
> > > As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
> > > should look at maybe making this a "<=" comparison instead since that is
> > > the
> > > only case I can think of where the packet would end up being entirely
> > > empty
> > > after eth_type_trans is called and we would be passing an skb with length
> > > 0.
> >
> > I likely didn’t understand your comment.
> > This driver check is before creating the skb for the received packet.
> > So, purpose is to not even process the packet header or prepare the skb if
> > it not an Ethernet frame.
> >
> > It is interesting to know when we get < 60B frame.
>
> If I recall, a UDPv4 frame can easily do it since Ethernet is 14B, IP
> header is 20, and UDP is only 8 so that only comes to 42B if I recall
> correctly. Similarly I think a TCPv4 Frame can be as small as 54B if
> you disable all the option headers.
>
> A quick and dirty test would be to run something like a netperf UDP_RR
> test. I know in the case of the network stack we see the transmits
> that go out are less than 60B until they are padded on xmit, usually
> by the device. My concern is wanting to make sure all those paths are
> covered before we assume that all the packets will be padded.
I was curious so I decided to try verifying things with a qemu w/ user
networking and virtio-net. From what I can tell it looks like it is
definitely not padding them out.
19:34:38.331376 IP (tos 0x0, ttl 64, id 31799, offset 0, flags [DF],
proto UDP (17), length 29)
localhost.localdomain.59579 > _gateway.52701: [udp sum ok] UDP, length 1
0x: 5255 0a00 0202 5254 0012 3456 0800 4500
0x0010: 001d 7c37 4000 4011 a688 0a00 020f 0a00
0x0020: 0202 e8bb cddd 0009 c331 6e
19:34:38.331431 IP (tos 0x0, ttl 64, id 45459, offset 0, flags [none],
proto UDP (17), length 29)
_gateway.52701 > localhost.localdomain.59579: [udp sum ok] UDP, length 1
0x: 5254 0012 3456 5255 0a00 0202 0800 4500
0x0010: 001d b193 4011 b12c 0a00 0202 0a00
0x0020: 020f cddd e8bb 0009 c331 6e
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next 1/2] virtio_net: Fix short frame length check
On Fri, Jan 13, 2023 at 3:37 PM Parav Pandit wrote:
>
>
> > From: Alexander H Duyck
> > Sent: Friday, January 13, 2023 6:24 PM
> >
> > On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > > any preemble and CRC.
> > >
> > > Current code only checks for minimal 14 bytes of Ethernet header length.
> > > Correct it to consider the minimum Ethernet frame length.
> > >
> > > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > > Signed-off-by: Parav Pandit
> > > ---
> > > drivers/net/virtio_net.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > > 7723b2a49d8e..d45e140b6852 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi,
> > struct receive_queue *rq,
> > > struct sk_buff *skb;
> > > struct virtio_net_hdr_mrg_rxbuf *hdr;
> > >
> > > - if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > > + if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> > > pr_debug("%s: short packet %i\n", dev->name, len);
> > > dev->stats.rx_length_errors++;
> > > if (vi->mergeable_rx_bufs) {
> >
> > I'm not sure I agree with this change as packets are only 60B if they have
> > gone
> > across the wire as they are usually padded out on the transmit side. There
> > may
> > be cases where software routed packets may not be 60B.
> >
> Do you mean Linux kernel software? Any link to it would be helpful.
The problem is there are several software paths involved and that is
why I am wanting to be cautious. As I recall this would impact Qemu
itself, DPDK, the Linux Kernel and several others if I am not
mistaken. That is why I am tending to err on the side of caution as
this is a pretty significant change.
> > As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
> > should look at maybe making this a "<=" comparison instead since that is the
> > only case I can think of where the packet would end up being entirely empty
> > after eth_type_trans is called and we would be passing an skb with length 0.
>
> I likely didn’t understand your comment.
> This driver check is before creating the skb for the received packet.
> So, purpose is to not even process the packet header or prepare the skb if it
> not an Ethernet frame.
>
> It is interesting to know when we get < 60B frame.
If I recall, a UDPv4 frame can easily do it since Ethernet is 14B, IP
header is 20, and UDP is only 8 so that only comes to 42B if I recall
correctly. Similarly I think a TCPv4 Frame can be as small as 54B if
you disable all the option headers.
A quick and dirty test would be to run something like a netperf UDP_RR
test. I know in the case of the network stack we see the transmits
that go out are less than 60B until they are padded on xmit, usually
by the device. My concern is wanting to make sure all those paths are
covered before we assume that all the packets will be padded.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH net-next 1/2] virtio_net: Fix short frame length check
> From: Alexander H Duyck
> Sent: Friday, January 13, 2023 6:24 PM
>
> On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > any preemble and CRC.
> >
> > Current code only checks for minimal 14 bytes of Ethernet header length.
> > Correct it to consider the minimum Ethernet frame length.
> >
> > Fixes: 296f96fcfc16 ("Net driver using virtio")
> > Signed-off-by: Parav Pandit
> > ---
> > drivers/net/virtio_net.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 7723b2a49d8e..d45e140b6852 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> > struct sk_buff *skb;
> > struct virtio_net_hdr_mrg_rxbuf *hdr;
> >
> > - if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> > + if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> > pr_debug("%s: short packet %i\n", dev->name, len);
> > dev->stats.rx_length_errors++;
> > if (vi->mergeable_rx_bufs) {
>
> I'm not sure I agree with this change as packets are only 60B if they have
> gone
> across the wire as they are usually padded out on the transmit side. There may
> be cases where software routed packets may not be 60B.
>
Do you mean Linux kernel software? Any link to it would be helpful.
> As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
> should look at maybe making this a "<=" comparison instead since that is the
> only case I can think of where the packet would end up being entirely empty
> after eth_type_trans is called and we would be passing an skb with length 0.
I likely didn’t understand your comment.
This driver check is before creating the skb for the received packet.
So, purpose is to not even process the packet header or prepare the skb if it
not an Ethernet frame.
It is interesting to know when we get < 60B frame.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next 2/2] virtio_net: Reuse buffer free function
On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> virtnet_rq_free_unused_buf() helper function to free the buffer
> already exists. Avoid code duplication by reusing existing function.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/net/virtio_net.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index d45e140b6852..c1faaf11fbcd 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1251,13 +1251,7 @@ static void receive_buf(struct virtnet_info *vi,
> struct receive_queue *rq,
> if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> pr_debug("%s: short packet %i\n", dev->name, len);
> dev->stats.rx_length_errors++;
> - if (vi->mergeable_rx_bufs) {
> - put_page(virt_to_head_page(buf));
> - } else if (vi->big_packets) {
> - give_pages(rq, buf);
> - } else {
> - put_page(virt_to_head_page(buf));
> - }
> + virtnet_rq_free_unused_buf(rq->vq, buf);
> return;
> }
>
Looks good to me.
Reviewed-by: Alexander Duyck
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next 1/2] virtio_net: Fix short frame length check
On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without any
> preemble and CRC.
>
> Current code only checks for minimal 14 bytes of Ethernet header length.
> Correct it to consider the minimum Ethernet frame length.
>
> Fixes: 296f96fcfc16 ("Net driver using virtio")
> Signed-off-by: Parav Pandit
> ---
> drivers/net/virtio_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7723b2a49d8e..d45e140b6852 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi, struct
> receive_queue *rq,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
>
> - if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
> + if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
> pr_debug("%s: short packet %i\n", dev->name, len);
> dev->stats.rx_length_errors++;
> if (vi->mergeable_rx_bufs) {
I'm not sure I agree with this change as packets are only 60B if they
have gone across the wire as they are usually padded out on the
transmit side. There may be cases where software routed packets may not
be 60B.
As such rather than changing out ETH_HLEN for ETH_ZLEN I wonder if we
should look at maybe making this a "<=" comparison instead since that
is the only case I can think of where the packet would end up being
entirely empty after eth_type_trans is called and we would be passing
an skb with length 0.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH net-next 2/2] virtio_net: Reuse buffer free function
virtnet_rq_free_unused_buf() helper function to free the buffer
already exists. Avoid code duplication by reusing existing function.
Signed-off-by: Parav Pandit
---
drivers/net/virtio_net.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d45e140b6852..c1faaf11fbcd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1251,13 +1251,7 @@ static void receive_buf(struct virtnet_info *vi, struct
receive_queue *rq,
if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
pr_debug("%s: short packet %i\n", dev->name, len);
dev->stats.rx_length_errors++;
- if (vi->mergeable_rx_bufs) {
- put_page(virt_to_head_page(buf));
- } else if (vi->big_packets) {
- give_pages(rq, buf);
- } else {
- put_page(virt_to_head_page(buf));
- }
+ virtnet_rq_free_unused_buf(rq->vq, buf);
return;
}
--
2.26.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH net-next 0/2] Small packet processing handling changes
Hi, These two changes improve the small packet handling. Patch summary: patch-1 fixes the length check by considering Ethernet 60B frame size patch-2 avoids code duplication by reuses existing buffer free helper Please review. Parav Pandit (2): virtio_net: Fix short frame length check virtio_net: Reuse buffer free function drivers/net/virtio_net.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) -- 2.26.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH net-next 1/2] virtio_net: Fix short frame length check
A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without any
preemble and CRC.
Current code only checks for minimal 14 bytes of Ethernet header length.
Correct it to consider the minimum Ethernet frame length.
Fixes: 296f96fcfc16 ("Net driver using virtio")
Signed-off-by: Parav Pandit
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7723b2a49d8e..d45e140b6852 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1248,7 +1248,7 @@ static void receive_buf(struct virtnet_info *vi, struct
receive_queue *rq,
struct sk_buff *skb;
struct virtio_net_hdr_mrg_rxbuf *hdr;
- if (unlikely(len < vi->hdr_len + ETH_HLEN)) {
+ if (unlikely(len < vi->hdr_len + ETH_ZLEN)) {
pr_debug("%s: short packet %i\n", dev->name, len);
dev->stats.rx_length_errors++;
if (vi->mergeable_rx_bufs) {
--
2.26.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 4/4] vdpa_sim: Implement resume vdpa op
On Tue, Jan 03, 2023 at 11:51:08AM +0100, sebastien.bo...@intel.com wrote:
From: Sebastien Boeuf
Implement resume operation for vdpa_sim devices, so vhost-vdpa will
offer that backend feature and userspace can effectively resume the
device.
Signed-off-by: Sebastien Boeuf
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 29 +
drivers/vdpa/vdpa_sim/vdpa_sim.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index b071f0d842fb..756a5db0109c 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -357,6 +357,12 @@ static void vdpasim_kick_vq(struct vdpa_device *vdpa, u16
idx)
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx];
+ if (!vdpasim->running &&
+ (vdpasim->status & VIRTIO_CONFIG_S_DRIVER_OK)) {
+ vdpasim->pending_kick = true;
+ return;
+ }
+
if (vq->ready)
schedule_work(&vdpasim->work);
}
@@ -527,6 +533,27 @@ static int vdpasim_suspend(struct vdpa_device *vdpa)
return 0;
}
+static int vdpasim_resume(struct vdpa_device *vdpa)
+{
+ struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+ int i;
+
+ spin_lock(&vdpasim->lock);
+ vdpasim->running = true;
+
+ if (vdpasim->pending_kick) {
IIUC if one of the vq receive a kick while the device is suspended, we
will kick all the vq.
At this point perhaps we should either send the kick only to the vqs we
should notify, or send it to all of them indiscriminately (I don't know
if it is correct to send a spurious kick).
Thanks,
Stefano
+ /* Process pending descriptors */
+ for (i = 0; i < vdpasim->dev_attr.nvqs; ++i)
+ vdpasim_kick_vq(vdpa, i);
+
+ vdpasim->pending_kick = false;
+ }
+
+ spin_unlock(&vdpasim->lock);
+
+ return 0;
+}
+
static size_t vdpasim_get_config_size(struct vdpa_device *vdpa)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
@@ -717,6 +744,7 @@ static const struct vdpa_config_ops vdpasim_config_ops = {
.set_status = vdpasim_set_status,
.reset = vdpasim_reset,
.suspend= vdpasim_suspend,
+ .resume = vdpasim_resume,
.get_config_size= vdpasim_get_config_size,
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
@@ -750,6 +778,7 @@ static const struct vdpa_config_ops
vdpasim_batch_config_ops = {
.set_status = vdpasim_set_status,
.reset = vdpasim_reset,
.suspend= vdpasim_suspend,
+ .resume = vdpasim_resume,
.get_config_size= vdpasim_get_config_size,
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h
index 0e78737dcc16..a745605589e2 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.h
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h
@@ -67,6 +67,7 @@ struct vdpasim {
u64 features;
u32 groups;
bool running;
+ bool pending_kick;
/* spinlock to synchronize iommu table */
spinlock_t iommu_lock;
};
--
2.37.2
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 3/4] vhost-vdpa: uAPI to resume the device
On Tue, Jan 03, 2023 at 11:51:07AM +0100, sebastien.bo...@intel.com wrote:
From: Sebastien Boeuf
This new ioctl adds support for resuming the device from userspace.
This is required when trying to restore the device in a functioning
state after it's been suspended. It is already possible to reset a
suspended device, but that means the device must be reconfigured and
all the IOMMU/IOTLB mappings must be recreated. This new operation
allows the device to be resumed without going through a full reset.
This is particularly useful when trying to perform offline migration of
a virtual machine (also known as snapshot/restore) as it allows the VMM
to resume the virtual machine back to a running state after the snapshot
is performed.
Acked-by: Jason Wang
Signed-off-by: Sebastien Boeuf
---
drivers/vhost/vdpa.c | 18 ++
include/uapi/linux/vhost.h | 8
2 files changed, 26 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 833617d00ef6..1db7bd39fb63 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -502,6 +502,21 @@ static long vhost_vdpa_suspend(struct vhost_vdpa *v)
return ops->suspend(vdpa);
}
+/* After a successful return of this ioctl the device resumes processing
+ * virtqueue descriptors. The device becomes fully operational the same way it
+ * was before it was suspended.
+ */
+static long vhost_vdpa_resume(struct vhost_vdpa *v)
+{
+ struct vdpa_device *vdpa = v->vdpa;
+ const struct vdpa_config_ops *ops = vdpa->config;
+
+ if (!ops->resume)
+ return -EOPNOTSUPP;
+
+ return ops->resume(vdpa);
+}
+
static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd,
void __user *argp)
{
@@ -687,6 +702,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
case VHOST_VDPA_SUSPEND:
r = vhost_vdpa_suspend(v);
break;
+ case VHOST_VDPA_RESUME:
+ r = vhost_vdpa_resume(v);
+ break;
default:
r = vhost_dev_ioctl(&v->vdev, cmd, argp);
if (r == -ENOIOCTLCMD)
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index f9f115a7c75b..92e1b700b51c 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -180,4 +180,12 @@
*/
#define VHOST_VDPA_SUSPEND _IO(VHOST_VIRTIO, 0x7D)
+/* Resume a device so it can resume processing virtqueue requests
+ *
+ * After the return of this ioctl the device will have restored all the
+ * necessary states and it is fully operational to continue processing the
+ * virtqueue descriptors.
IIUC this is a no-op if the device wasn't suspended.
If you have to resend, maybe add this info also here in the user
documentation.
Anyway, the patch LGTM:
Reviewed-by: Stefano Garzarella
+ */
+#define VHOST_VDPA_RESUME _IO(VHOST_VIRTIO, 0x7E)
+
#endif
--
2.37.2
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 2/4] vhost-vdpa: Introduce RESUME backend feature bit
On Tue, Jan 03, 2023 at 11:51:06AM +0100, sebastien.bo...@intel.com wrote:
From: Sebastien Boeuf
Userspace knows if the device can be resumed or not by checking this
feature bit.
It's only exposed if the vdpa driver backend implements the resume()
operation callback. Userspace trying to negotiate this feature when it
hasn't been exposed will result in an error.
Acked-by: Jason Wang
Signed-off-by: Sebastien Boeuf
---
drivers/vhost/vdpa.c | 16 +++-
include/uapi/linux/vhost_types.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 166044642fd5..833617d00ef6 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -355,6 +355,14 @@ static bool vhost_vdpa_can_suspend(const struct vhost_vdpa
*v)
return ops->suspend;
}
+static bool vhost_vdpa_can_resume(const struct vhost_vdpa *v)
+{
+ struct vdpa_device *vdpa = v->vdpa;
+ const struct vdpa_config_ops *ops = vdpa->config;
+
+ return ops->resume;
+}
+
static long vhost_vdpa_get_features(struct vhost_vdpa *v, u64 __user *featurep)
{
struct vdpa_device *vdpa = v->vdpa;
@@ -602,11 +610,15 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
if (copy_from_user(&features, featurep, sizeof(features)))
return -EFAULT;
if (features & ~(VHOST_VDPA_BACKEND_FEATURES |
-BIT_ULL(VHOST_BACKEND_F_SUSPEND)))
+BIT_ULL(VHOST_BACKEND_F_SUSPEND) |
+BIT_ULL(VHOST_BACKEND_F_RESUME)))
return -EOPNOTSUPP;
if ((features & BIT_ULL(VHOST_BACKEND_F_SUSPEND)) &&
!vhost_vdpa_can_suspend(v))
return -EOPNOTSUPP;
+ if ((features & BIT_ULL(VHOST_BACKEND_F_RESUME)) &&
+!vhost_vdpa_can_resume(v))
+ return -EOPNOTSUPP;
Not for this patch, but I'd like to refactor this code a bit to fill a
`backend_features` field in vhost_vdpa during the vhost_vdpa_probe(), so
we don't need to change this code or the VHOST_GET_BACKEND_FEATURES for
every new backend feature.
I'll send a patch.
This LGTM:
Reviewed-by: Stefano Garzarella
vhost_set_backend_features(&v->vdev, features);
return 0;
}
@@ -658,6 +670,8 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
features = VHOST_VDPA_BACKEND_FEATURES;
if (vhost_vdpa_can_suspend(v))
features |= BIT_ULL(VHOST_BACKEND_F_SUSPEND);
+ if (vhost_vdpa_can_resume(v))
+ features |= BIT_ULL(VHOST_BACKEND_F_RESUME);
if (copy_to_user(featurep, &features, sizeof(features)))
r = -EFAULT;
break;
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index 53601ce2c20a..c5690a8992d8 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -163,5 +163,7 @@ struct vhost_vdpa_iova_range {
#define VHOST_BACKEND_F_IOTLB_ASID 0x3
/* Device can be suspended */
#define VHOST_BACKEND_F_SUSPEND 0x4
+/* Device can be resumed */
+#define VHOST_BACKEND_F_RESUME 0x5
#endif
--
2.37.2
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 1/4] vdpa: Add resume operation
On Tue, Jan 03, 2023 at 11:51:05AM +0100, sebastien.bo...@intel.com wrote:
From: Sebastien Boeuf
Add a new operation to allow a vDPA device to be resumed after it has
been suspended. Trying to resume a device that wasn't suspended will
result in a no-op.
This operation is optional. If it's not implemented, the associated
backend feature bit will not be exposed. And if the feature bit is not
exposed, invoking this operation will return an error.
Acked-by: Jason Wang
Signed-off-by: Sebastien Boeuf
---
include/linux/vdpa.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Stefano Garzarella
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 6d0f5e4e82c2..96d308cbf97b 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -219,7 +219,10 @@ struct vdpa_map_file {
* @reset: Reset device
* @vdev: vdpa device
* Returns integer: success (0) or error (< 0)
- * @suspend: Suspend or resume the device (optional)
+ * @suspend: Suspend the device (optional)
+ * @vdev: vdpa device
+ * Returns integer: success (0) or error (< 0)
+ * @resume:Resume the device (optional)
* @vdev: vdpa device
* Returns integer: success (0) or error (< 0)
* @get_config_size:Get the size of the configuration space includes
@@ -324,6 +327,7 @@ struct vdpa_config_ops {
void (*set_status)(struct vdpa_device *vdev, u8 status);
int (*reset)(struct vdpa_device *vdev);
int (*suspend)(struct vdpa_device *vdev);
+ int (*resume)(struct vdpa_device *vdev);
size_t (*get_config_size)(struct vdpa_device *vdev);
void (*get_config)(struct vdpa_device *vdev, unsigned int offset,
void *buf, unsigned int len);
--
2.37.2
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
