qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: persistent tun & different virtual NICs & dead guest ne


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: persistent tun & different virtual NICs & dead guest network
Date: Thu, 9 Jul 2009 21:13:17 +0300
User-agent: Mutt/1.5.19 (2009-01-05)

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 <address@hidden>
> 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 <address@hidden>
> ---
>  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 via email to

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