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.
