From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlxO-0001J8-FT for qemu-devel@nongnu.org; Wed, 25 Sep 2013 06:04:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOlxF-0004Ia-1Q for qemu-devel@nongnu.org; Wed, 25 Sep 2013 06:04:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOlxE-0004IT-Py for qemu-devel@nongnu.org; Wed, 25 Sep 2013 06:04:20 -0400 Date: Wed, 25 Sep 2013 13:06:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20130925100631.GB7876@redhat.com> References: <20130922085920.GB32658@redhat.com> <20130925093127.GB6320@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC] sync NIC's MAC maintained in NICConf as soon as emualted NIC's MAC changed in guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Zhanghaoyu (A)" Cc: "chenliang (T)" , "Huangweidong (C)" , Gleb Natapov , "paolo.bonzini@gmail.com" , Jason Wang , Luonengjun , qemu-devel , Xiahai On Wed, Sep 25, 2013 at 09:55:02AM +0000, Zhanghaoyu (A) wrote: > >> >> Hi, all > >> >> > >> >> Do live migration if emulated NIC's MAC has been changed, RARP with > >> >> wrong MAC address will broadcast via qemu_announce_self in destination, so, long time network disconnection probably happen. > >> > > >> >Good catch. > >> > > >> >> I want to do below works to resolve this problem, 1. change > >> >> NICConf's MAC as soon as emulated NIC's MAC changed in guest > >> > > >> >This will make it impossible to revert it correctly on reset, won't it? > >> > > >> You are right. > >> virsh reboot , or virsh reset , or reboot VM from guest, will revert emulated NIC's MAC to original one maintained in NICConf. > >> During the reboot/reset flow in qemu, emulated NIC's reset handler > >> will sync the MAC address in NICConf to the MAC address in emulated NIC structure, e.g., virtio_net_reset sync the MAC address in NICConf to VirtIONet'mac. > >> > >> BTW, in native scenario, reboot will revert the changed MAC to original one, too. > >> > >> >> 2. sync NIC's (more precisely, queue) MAC to corresponding NICConf > >> >> in NIC's migration load handler > >> >> > >> >> Any better ideas? > >> >> > >> >> Thanks, > >> >> Zhang Haoyu > >> > > >> >I think announce needs to poke at the current MAC instead of the default one in NICConf. > >> >We can make it respect link down state while we are at it. > >> > > >> NICConf structures are incorporated in different emulated NIC's > >> structure, e.g., VirtIONet, E1000State_st, RTL8139State, etc., since so many kinds of emulated NICs, they are described by different structures, how to find all NICs' current MAC? > >> > >> Maybe we can introduce a pointer member 'current_mac' to NICConf > >> structure, which points to the current MAC, then we can find all current MACs from NICConf.current_mac. > > > >I wouldn't make it a pointer, just a buffer with the mac, copy it there. > >Maybe call it "softmac" that's what it is really. > > > >> Can we broadcast the RARP with current MAC in NIC's migration load handler respectively? > >> > >> Thanks, > >> Zhang Haoyu > > > >It's not so simple, you need to retry several times. > > > Could you make a statement for 'retry several times' ? > Is it the process of retrying several times to sending RARP in qemu_announce_self_once? yes > 'broadcast the RARP with current MAC in NIC's migration load handler respectively' is distributing the job of what qemu_announce_self does to every NIC's migration load handler, > e.g., in virtio NIC's migration load handler virtio_net_load, we can create a timer to retry several times to send ARAP with current MAC for this NIC, just as same as qemu_announce_self does. I don't see a lot of value in this yet. > >> >Happily recent linux guests aren't affected since they do announcements from guest. > >> > > >> >-- > >> >MST