From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>, KVM list <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: persistent tun & different virtual NICs & dead guest network
Date: Thu, 9 Jul 2009 21:13:17 +0300 [thread overview]
Message-ID: <20090709181317.GB4340@redhat.com> (raw)
In-Reply-To: <49D8A014.7010802@redhat.com>
On Sun, Apr 05, 2009 at 03:12:04PM +0300, Avi Kivity wrote:
> Avi Kivity wrote:
>>> 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.
>>
>
> Okay, that's not in upstream qemu, so I committed a fix to
> kvm-userspace.git.
>
> Attached if you want to test it.
>
> --
> error compiling committee.c: too many arguments to function
>
> >From 25971710409c374e9486c960c297f324a9164a65 Mon Sep 17 00:00:00 2001
> From: Avi Kivity <avi@redhat.com>
> Date: Sun, 5 Apr 2009 15:08:55 +0300
> Subject: [PATCH] kvm: qemu: clear tap features on initialization
>
> tap features change how tap interprets data, so they must be cleared on
> initialization to prevent old settings from interfering with new guest
> instances.
>
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
> qemu/net.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/qemu/net.c b/qemu/net.c
> index d753fa0..703d01c 100644
> --- a/qemu/net.c
> +++ b/qemu/net.c
> @@ -930,6 +930,7 @@ static TAPState *net_tap_fd_init(VLANState *vlan,
> #endif
> #ifdef TUNSETOFFLOAD
> s->vc->set_offload = tap_set_offload;
> + tap_set_offload(s->vc, 0, 0, 0, 0);
BTW, should not these bits be restored on load?
I couldn't find code that does this.
> #endif
> qemu_set_fd_handler2(s->fd, tap_can_send, tap_send, NULL, s);
> snprintf(s->vc->info_str, sizeof(s->vc->info_str), "fd=%d", fd);
Looks good to me. Just a thought: do we want kernel to give us an
option to tie the offload bits to the character device, so that it gets
cleaned automatically when qemu dies?
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
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: Thu, 9 Jul 2009 21:13:17 +0300 [thread overview]
Message-ID: <20090709181317.GB4340@redhat.com> (raw)
In-Reply-To: <49D8A014.7010802@redhat.com>
On Sun, Apr 05, 2009 at 03:12:04PM +0300, Avi Kivity wrote:
> Avi Kivity wrote:
>>> 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.
>>
>
> Okay, that's not in upstream qemu, so I committed a fix to
> kvm-userspace.git.
>
> Attached if you want to test it.
>
> --
> error compiling committee.c: too many arguments to function
>
> >From 25971710409c374e9486c960c297f324a9164a65 Mon Sep 17 00:00:00 2001
> From: Avi Kivity <avi@redhat.com>
> Date: Sun, 5 Apr 2009 15:08:55 +0300
> Subject: [PATCH] kvm: qemu: clear tap features on initialization
>
> tap features change how tap interprets data, so they must be cleared on
> initialization to prevent old settings from interfering with new guest
> instances.
>
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
> qemu/net.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/qemu/net.c b/qemu/net.c
> index d753fa0..703d01c 100644
> --- a/qemu/net.c
> +++ b/qemu/net.c
> @@ -930,6 +930,7 @@ static TAPState *net_tap_fd_init(VLANState *vlan,
> #endif
> #ifdef TUNSETOFFLOAD
> s->vc->set_offload = tap_set_offload;
> + tap_set_offload(s->vc, 0, 0, 0, 0);
BTW, should not these bits be restored on load?
I couldn't find code that does this.
> #endif
> qemu_set_fd_handler2(s->fd, tap_can_send, tap_send, NULL, s);
> snprintf(s->vc->info_str, sizeof(s->vc->info_str), "fd=%d", fd);
Looks good to me. Just a thought: do we want kernel to give us an
option to tie the offload bits to the character device, so that it gets
cleaned automatically when qemu dies?
--
MST
next prev parent reply other threads:[~2009-07-09 18:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-04 10:26 persistent tun & different virtual NICs & dead guest network Michael Tokarev
2009-04-05 11:58 ` Avi Kivity
2009-04-05 11:58 ` [Qemu-devel] " Avi Kivity
2009-04-05 12:12 ` Avi Kivity
2009-04-05 12:12 ` [Qemu-devel] " Avi Kivity
2009-07-09 18:13 ` Michael S. Tsirkin [this message]
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=20090709181317.GB4340@redhat.com \
--to=mst@redhat.com \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.