Re: [Qemu-devel] [PATCH V7 0/5] Send the gratuitous by guest

[Michael S. Tsirkin]

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?

> and then maybe we can just do this
> unconditionally in vm_start().

OK but then the new infrastructure we are adding will be dead code,
won't it?

Can we do this simply using a post load hook for now?

>
> >> - decide whether to send gratuitous packets by previous runstate instead 
> >> of a dedicated parameter
> >> - check virtio_net_started() instead of VIRTIO_NET_S_LINK_UP before issue 
> >> the config update interrupt
> >> - move VIRTIO_NET_S_ANNOUNCE to 0x100 and supress guest config write to RO 
> >> bits
> >> - cleanups suggested by Michael
> >>
> >> Tested with migration within 802.1Q.
> >>
> >> Jason Wang (5):
> >>   runstate: introduce prelaunch-migrate state
> >>   net: announce self after vm is started
> >>   net: model specific announcing support
> >>   virtio-net: notify guest to annouce itself
> >>   virtio-net: compat guest announce
> >>
> >>  hw/pc.h           |    6 +++++-
> >>  hw/virtio-net.c   |   30 ++++++++++++++++++++++++++++++
> >>  hw/virtio-net.h   |   15 ++++++++++++++-
> >>  include/net/net.h |    2 ++
> >>  migration.c       |    4 +---
> >>  qapi-schema.json  |    5 ++++-
> >>  savevm.c          |    8 ++++++--
> >>  vl.c              |    8 +++++++-
> >>  8 files changed, 69 insertions(+), 9 deletions(-)