From: Avi Kivity <avi@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: [Qemu-devel] Re: persistent tun & different virtual NICs & dead guest network
Date: Sun, 05 Apr 2009 14:58:48 +0300 [thread overview]
Message-ID: <49D89CF8.8040200@redhat.com> (raw)
In-Reply-To: <49D735D6.3070803@msgid.tls.msk.ru>
(cc qemu-devel)
Michael Tokarev wrote:
> Hello.
>
> 2 days debugging an.. issue here, and finally got it.
> To make the long and painful (it was for me anyway)
> story short...
>
> kvm provides a way to control various offload settings
> on the "host side" of the tun network device (I mean
> the `-net tap' setup) from within guest. I.e., guest
> can set/clear various offload bits according to its
> capabilities/wishes.
>
> The problem is that different virtual NICs as used by
> kvm/qemu expects and sets different offload bits for
> the virtual NIC. And sets only those bits which -
> as they "think" - differs from the default (all-off).
>
> This means that when changing virtual NIC model AND
> using persistent tun device, it's very likely to get
> inconsistent flags.
>
> For example, here's how the offload settings on the
> host looks like after using e1000 driver in guest
> (freshly created persistent tun device):
>
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: on
> udp fragmentation offload: off
> generic segmentation offload: off
> large receive offload: off
>
> Here's the same setting when using virtio_net
> instead:
>
> rx-checksumming: on
> tx-checksumming: off
> scatter-gather: off
> tcp segmentation offload: off
> udp fragmentation offload: off
> generic segmentation offload: off
> large receive offload: off
>
> I.e., only rx-checksumming. When using virtio_net
> from 2.6.29, which supports LRO, it also turns on
> large receive offload.
>
> Now, say, I tried a host with e1000 driver, and it
> turned on tx, sg and tso bits. And now I'm trying
> to run a guest with new virtio-net NIC instead. It
> turns on lro bit, but the network does not work anyway:
> almost any packet that's being sent from host to the
> guest has incorrect checksum - because the NIC is marked
> as able to do tx-checksumming but it does not do it.
> The network is dead.
>
> Now, after trying that and this, not understanding
> what's going on etc, let's reboot back with e1000
> NIC which worked a few minutes ago... just to discover
> that it does not work anymore too! Because previous
> attempt with virtio_net resulted in lro being on, but
> the driver does not support it! So now, we've non-
> working network again, and now, it does not matter
> which driver we'll try: neither of them will work
> because the offload settings are broken.
>
> It's more: one can't control this stuff from the
> host side using standard ethtool: it says that
> the operation is not supported (I wonder how kvm
> performs the settings changes).
>
> The solution here is to re-create the tun device
> before changing the virtual NIC model. But it
> isn't always possible, esp. when guests are
> being run from non-root user (where persistent
> tun devices are most useful).
>
> Can this be fixed somehow please?
>
> I think all the settings should be reset to 0
> when opening the tun device.
This should definitely be fixed. I'll look at writing a patch.
--
error compiling committee.c: too many arguments to function
next parent reply other threads:[~2009-04-05 11:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49D735D6.3070803@msgid.tls.msk.ru>
2009-04-05 11:58 ` Avi Kivity [this message]
2009-04-05 12:12 ` [Qemu-devel] Re: persistent tun & different virtual NICs & dead guest network Avi Kivity
2009-07-09 18:13 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D89CF8.8040200@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).