Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network

[Mark McLoughlin]

Hi Dustin,

On Wed, 2009-10-28 at 14:22 -0500, Dustin Kirkland wrote:
> I believe that we have identified a regression in qemu-kvm-0.11.0.

Regression versus which previous version of qemu-kvm?

> The kvm process crashes for older guests with virtio networking, when
> the guest's incoming network connection is saturated.  The subject
> guest is Ubuntu 8.04 Hardy, 2.6.24 kernel with virtio backports.

It'd be good to see your virtio_net code

e.g. it should not have the VIRTIO_NET_F_GUEST_TSO4 feature set if it
doesn't have the "big_packets" code in try_fill_recv()

> For your convenience, I have uploaded a stock, ~260MB Ubuntu 8.04 disk
> image (user/pw = ubuntu) that I'm using to reproduce the problem at:
>  * http://rookery.canonical.com/~kirkland/hardy.img.bz2
> 
> The command line is:
>  * sudo /usr/bin/kvm -m 512 -net nic,model=virtio -net
> tap,script=/home/kirkland/bin/bridge.sh -drive
> file=hardy.img,if=virtio,index=0,boot=on
> 
> The bridge script is:
>  * http://rookery.canonical.com/~kirkland/bridge.sh
> 
> I'm saturating the guest's incoming network connection, with:
>   address@hidden nc -lp 1234 > /dev/null
> and
>   address@hidden cat /dev/urandom | nc -w 3 guest_ip 1234
> 
> In less than a second of sending, the vm crashes with:
>   virtio-net truncating packet

Assuming this is something like the virtio-net in 2.6.26, there was no
receivable buffers support so (as Scott points out) it must be that
we've read a packet from the tap device which is >1514 bytes (or >1524
bytes with IFF_VNET_HDR) but the guest has not supplied buffers which
are large enough to take it

One thing to check is that the tap device is being initialized by
qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO
should not be enabled, because the guest cannot handle large GSO packets

Another possibility is that the MTU on the bridge in the host is too
large and that's what's causing the large packets to be sent

I agree we shouldn't exit in this scenario, but let's figure out what's
causing it to occur

Cheers,
Mark.