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

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 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 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 drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not

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 drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not

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

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

On Mon, Dec 23, 2019 at 3:22 PM Alistair Delva <adelva at google.com> wrote: > > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn > <willemdebruijn.kernel at gmail.com> wrote: > > > > On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn > > <willemdebruijn.kernel at gmail.com> wrote: > > > > > > 00fffe0ff0 DR7: 0000000000000400 > >

On Mon, Dec 23, 2019 at 12:21:56PM -0800, Alistair Delva wrote: > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn > <willemdebruijn.kernel at gmail.com> wrote: > > > > On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn > > <willemdebruijn.kernel at gmail.com> wrote: > > > > > > 00fffe0ff0 DR7: 0000000000000400 > > > > > Call

On 2019/12/24 ??4:21, Alistair Delva wrote: > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn > <willemdebruijn.kernel at gmail.com> wrote: >> On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn >> <willemdebruijn.kernel at gmail.com> wrote: >>> 00fffe0ff0 DR7: 0000000000000400 >>>>> Call Trace: >>>>> ?

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 Fri, Feb 22, 2019 at 12:26:10PM +0200, Jarkko Sakkinen wrote: > On Thu, Feb 21, 2019 at 06:14:02PM -0800, David Tolnay wrote: > > Add a config TCG_VIRTIO_VTPM which enables a driver providing the guest > > kernel side of TPM over virtio. > > > > Use case: TPM support is needed for performing trusted work from within > > a virtual machine launched by Chrome OS.