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

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

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

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

Hello, In my testing of crosvm[1] with Linux 4.4.175, I am observing failures on a 'kevin' Chromebook (RK3399) device - the guest kernel does not even get to the point of printing its first messages, and the host seems to be spinning at 100% CPU in KVM_RUN. I narrowed this down to the 4.4 stable backport of "arm64: KVM: Skip MMIO insn after emulation" - with this patch

Hello, In my testing of crosvm[1] with Linux 4.4.175, I am observing failures on a 'kevin' Chromebook (RK3399) device - the guest kernel does not even get to the point of printing its first messages, and the host seems to be spinning at 100% CPU in KVM_RUN. I narrowed this down to the 4.4 stable backport of "arm64: KVM: Skip MMIO insn after emulation" - with this patch