From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UExQq-00087H-5P for qemu-devel@nongnu.org; Mon, 11 Mar 2013 03:46:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UExQo-0005i3-Ii for qemu-devel@nongnu.org; Mon, 11 Mar 2013 03:46:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UExQo-0005ho-Ao for qemu-devel@nongnu.org; Mon, 11 Mar 2013 03:46:02 -0400 Message-ID: <513D8BAC.3010702@redhat.com> Date: Mon, 11 Mar 2013 15:45:48 +0800 From: Jason Wang MIME-Version: 1.0 References: <1362644631-23113-1-git-send-email-jasowang@redhat.com> <20130307100449.GA5302@redhat.com> <51386855.2080801@redhat.com> <20130307102544.GA5697@redhat.com> <51386CFA.7070006@redhat.com> <20130307105242.GA5823@redhat.com> <20130308110317.GD32107@stefanha-thinkpad.redhat.com> In-Reply-To: <20130308110317.GD32107@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: aliguori@us.ibm.com, gleb@redhat.com, Juan Quintela , "Michael S. Tsirkin" , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com On 03/08/2013 07:03 PM, Stefan Hajnoczi wrote: > On Thu, Mar 07, 2013 at 12:52:42PM +0200, Michael S. Tsirkin wrote: >> On Thu, Mar 07, 2013 at 06:33:30PM +0800, Jason Wang wrote: >>> On 03/07/2013 06:25 PM, Michael S. Tsirkin wrote: >>>> On Thu, Mar 07, 2013 at 06:13:41PM +0800, Jason Wang wrote: >>>>> On 03/07/2013 06:04 PM, Michael S. Tsirkin wrote: >>>>>> On Thu, Mar 07, 2013 at 04:23:46PM +0800, Jason Wang wrote: >>>>>>> This series tries to let guest instead of qemu to send the gratuitous packets >>>>>>> after migration when guest is capable of doing this. This is needed since it's >>>>>>> impossible for qemu to keep track of all configurations (e.g 802.1Q) and mac >>>>>>> addresses (more than one mac address may be used by guest). So qemu can't build >>>>>>> gratuitous packets for all those configurations properly. The only solution is >>>>>>> let guest driver who knew all needed information to do this. >>>>>>> >>>>>>> The series first introduces a new runstate which just tracks the state when the >>>>>>> migration is finished and guest is about to start. And then we can just trying >>>>>>> to notify the guest to send the GARP after changing from this state to >>>>>>> running. A model specific announcing method were also also introduced to let >>>>>>> each kinds of nic do its own notification. When there's no such method register >>>>>>> for the nic, the old style of sending RARP were kept. And the last two patches >>>>>>> implemented the virtio-net method of notification. >>>>>> Do we want to retry SELF_ANNOUNCE_ROUNDS? >>>>> Yes, we do the announcement several times like in the past. >>>>>>> Changes from V6: >>>>>>> - introduce a new runstate instead of using a global variable check the state >>>>>>> >>>>>>> Changes from V5: >>>>>>> - use a global variable to decide whether an announcement is needed after migration >>>>>>> - align with virtio spec and let guest ack the announcement notification through >>>>>>> control vq instead of config status writing >>>>>>> >>>>>>> Changes from V4: >>>>>>> - keep the old behavior that send the gratuitous packets only after migration >>>>>> I wonder why it's a sane thing to do. How about simply sending the event after load? >>>>> The aim is to limit the change of the behaviour to focus on migration. >>>>> We may also need this after cont, >>>> Hmm why after cont? >>> If we stop the vm for a long period, the mac will be missed in the >>> forward table of the bridge also. >> Hmm okay, needs some thought. > One case where a physical machine is offline for a long time is > Wake-on-LAN. Broadcast is used exactly for this reason. > > If a switch receives a packet to an unknown MAC it must broadcast. If a > host doesn't have a IP-to-MAC table entry (due to timeout) it must send > an ARP request. > > So I think this is all handled by existing behavior. If other hosts > have forgotten about the VM's MAC they will send an ARP request, which > the VM will respond to if it is running again. > > Stefan Right, thanks for the clarification. So the only thing qemu needs to care is migration.