| Message ID | d9c105ea0904060955q799e52ffvb7ee45fb3cde5695@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Mon, 2009-04-06 at 09:55 -0700, Dustin Kirkland wrote: > On Tue, Mar 31, 2009 at 5:28 PM, Dustin Kirkland <kirkland@canonical.com> wrote: > > I'm receiving a heavy volume of Ubuntu Jaunty Beta users reporting > > that Jaunty hosts running kvm-84 (userspace and kernel) are not able > > to boot previously-working Hardy guests (2.6.24 kernel) if virtio > > networking is enabled [1]. Users report that if e1000 is used > > instead, the guest is able to boot (with degraded network performance, > > obviously). Users are also reporting that this was not a problem when > > kvm-82 was used in Jaunty (though we also merged libvirt 0.5.1 up to > > 0.6.0 in roughly the same timeframe). > ... > > [1] https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/331128 > > Howdy- > > Just a follow-up... > > Anthony was able to confirm this issue, and create a patch for KVM, > which we're carrying in Ubuntu. It's a bit of a special-case hack, > but I'm dropping it here for the sake of completeness. > > Basically, Hardy guests do not have working GSO (general segment > offload) support. Some changes in kvm/libvirt appear to be exposing > this, and breaking some guests when running virtio. > > This patch from Anthony basically disables this support in KVM > userspace (until we have a better solution for auto-detecting GSO > support or lack thereof). The problem here is that 2.6.24/5 vintage guests are saying they support something they don't. See this for further details: http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2009-04-06 at 18:43 +0100, Mark McLoughlin wrote: > The problem here is that 2.6.24/5 vintage guests are saying they > support > something they don't. See this for further details: > > http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html Agreed, understood. And those kernels should be patched. However, it's a bit of a chicken/egg problem... One can't even boot those guests (with virtio) to update the kernel, as it panics on boot (without the kvm hack). :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dustin Kirkland wrote: > On Mon, 2009-04-06 at 18:43 +0100, Mark McLoughlin wrote: > >> The problem here is that 2.6.24/5 vintage guests are saying they >> support >> something they don't. See this for further details: >> >> http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html >> > > Agreed, understood. And those kernels should be patched. > > However, it's a bit of a chicken/egg problem... One can't even boot > those guests (with virtio) to update the kernel, as it panics on boot > (without the kvm hack). > There's now a fix for this in QEMU stable. It'll make it's way to kvm-userspace once Avi merges. Regards, Anthony Liguori > :-Dustin > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c index 9bce3a0..5b615f9 100644 --- a/qemu/hw/virtio-net.c +++ b/qemu/hw/virtio-net.c @@ -120,6 +120,9 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev) if (tap_has_vnet_hdr(host)) { tap_using_vnet_hdr(host, 1); +#if 0 + /* Stop advertising advanced features until we work around the fact + * that this is totally broken in 2.6.26 kernels */ features |= (1 << VIRTIO_NET_F_CSUM); features |= (1 << VIRTIO_NET_F_GUEST_CSUM); features |= (1 << VIRTIO_NET_F_GUEST_TSO4); @@ -130,6 +133,7 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev) features |= (1 << VIRTIO_NET_F_HOST_ECN); features |= (1 << VIRTIO_NET_F_MRG_RXBUF); /* Kernel can't actually handle UFO in software currently. */ +#endif } #endif @@ -374,8 +378,14 @@ static int receive_header(VirtIONet *n, struct iovec *iov, int iovcnt, struct virtio_net_hdr *hdr = iov[0].iov_base; int offset = 0; +#if 0 hdr->flags = 0; hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE; +#else + /* we need to clear out the whole header, including any garbage that may be + */ + memset(hdr, 0, sizeof(*hdr)); +#endif #ifdef TAP_VNET_HDR