similar to: [PATCH net] virtio-net: Skip set_features on non-cvq devices

On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > > > On devices without control virtqueue support, such as the virtio_net > > > implementation in crosvm[1],

On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > > > On devices without control virtqueue support, such as the virtio_net > > > implementation in crosvm[1],

On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > > > On Fri, Dec 20, 2019 at 4:22

On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > > > On Fri, Dec 20, 2019 at 4:22

On Sun, Dec 22, 2019 at 4:12 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Sun, Dec 22, 2019 at 10:54:23AM -0500, Willem de Bruijn wrote: > > On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > > > On Sun, Dec 22, 2019 at 8:11

On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > On devices without control virtqueue support, such as the virtio_net > > implementation in crosvm[1], attempting to configure LRO will panic the > > kernel: > > > > kernel BUG at

On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > > > > > On devices without

On Fri, Dec 20, 2019 at 01:22:07PM -0800, Alistair Delva wrote: > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not tainted

On Fri, Dec 20, 2019 at 01:22:07PM -0800, Alistair Delva wrote: > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not tainted

On Sun, Dec 22, 2019 at 10:54:23AM -0500, Willem de Bruijn wrote: > On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > > > On Fri, Dec 20, 2019

On Fri, Dec 20, 2019 at 1:22 PM Alistair Delva <adelva at google.com> wrote: > > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: If you'd like to try using the control virtqueue, I have a WIP patch at crrev.com/c/1968200 The downside there is that when enabling IP

00fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > ? preempt_count_add+0x58/0xb0 > > ? _raw_spin_lock_irqsave+0x36/0x70 > > ? _raw_spin_unlock_irqrestore+0x1a/0x40 > > ? __wake_up+0x70/0x190 > > virtnet_set_features+0x90/0xf0 [virtio_net] > > __netdev_update_features+0x271/0x980 > > ? nlmsg_notify+0x5b/0xa0 > >

00fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > ? preempt_count_add+0x58/0xb0 > > ? _raw_spin_lock_irqsave+0x36/0x70 > > ? _raw_spin_unlock_irqrestore+0x1a/0x40 > > ? __wake_up+0x70/0x190 > > virtnet_set_features+0x90/0xf0 [virtio_net] > > __netdev_update_features+0x271/0x980 > > ? nlmsg_notify+0x5b/0xa0 > >

On Mon, Dec 23, 2019 at 09:40:11AM -0800, Alistair Delva wrote: > Hi Michael, > > On Mon, Dec 23, 2019 at 6:09 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > The only way for guest to control offloads (as enabled by > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands > > through CTRL_VQ. So it does not make sense to > > acknowledge

The only way for guest to control offloads (as enabled by VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands through CTRL_VQ. So it does not make sense to acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without VIRTIO_NET_F_CTRL_VQ. The spec does not outlaw devices with such a configuration, but Linux assumed that with VIRTIO_NET_F_CTRL_GUEST_OFFLOADS control vq is always there, resulting in

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On 5/16/19 10:35 PM, Pankaj Gupta wrote: > Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch :)I don't feel that I have enough expertise to give the reviewed-by tag, but you can take my acked-by + tested-by. Acked-by: Jakub Staron <jstaron at google.com> Tested-by: Jakub Staron <jstaron at google.com> No kernel panics/stalls encountered during

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

The only way for guest to control offloads (as enabled by VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands through CTRL_VQ. So it does not make sense to acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without VIRTIO_NET_F_CTRL_VQ. The spec does not outlaw devices with such a configuration, so we have to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. Note that Linux is still