qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

      reply	other threads:[~2009-07-09 18:14 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 ` [Qemu-devel] Re: persistent tun & different virtual NICs & dead guest network Avi Kivity
2009-04-05 12:12   ` Avi Kivity
2009-07-09 18:13     ` Michael S. Tsirkin [this message]

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 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).