qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark McLoughlin
Subject: Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
Date: Thu, 29 Oct 2009 12:16:06 +0000

On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote:
> Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009:
> > 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
> 
> Using Dustin's image, I see:
>       virtio_net_set_features(features: 0x00000930)

Hmm - 0x930 doesn't seem right. Is that 930 decimal, 0x3a2 hex?

>       tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1)
> being called and get an mtu of 1500 on virbr0 using his birdge.sh script.
> 
> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 
> 10 'virtio_net_hdr')
> and the guest only had 1524 bytes of space in its input descriptors.

Okay, that sounds like a bug in Dustin's version of the guest virtio-net
driver - if it is only supplying 1524 byte buffers, it should not be
saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature

Cheers,
Mark.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]