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

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

[Jason Wang]

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.

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
- 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(-)

[Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state

[Jason Wang]

Sometimes, we need track the state when guest is just about to start after
migration. There's not a accurate state available which do this accurately
(consider qemu may started with -S in destination).

So this patch introduces a new state prelaunch-migrate which just tracks this
state, it covers the case both w/ and w/o -S in destination. The first user of
this is the support of doing announce by guest.

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 migration.c      |    3 +--
 qapi-schema.json |    5 ++++-
 vl.c             |    4 +++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/migration.c b/migration.c
index 11725ae..ecdf2c5 100644
--- a/migration.c
+++ b/migration.c
@@ -107,10 +107,9 @@ static void process_incoming_migration_co(void *opaque)
     /* Make sure all file formats flush their mutable metadata */
     bdrv_invalidate_cache_all();
 
+    runstate_set(RUN_STATE_PRELAUNCH_MIGRATE);
     if (autostart) {
         vm_start();
-    } else {
-        runstate_set(RUN_STATE_PAUSED);
     }
 }
 
diff --git a/qapi-schema.json b/qapi-schema.json
index 28b070f..baa6361 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -174,11 +174,14 @@
 # @suspended: guest is suspended (ACPI S3)
 #
 # @watchdog: the watchdog action is configured to pause and has been triggered
+#
+# @migrate-prelaunch: migration is completed and QEMU were started with -S
 ##
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
+            'prelaunch-migrate'] }
 
 ##
 # @SnapshotInfo
diff --git a/vl.c b/vl.c
index c03edf1..5dd2e0e 100644
--- a/vl.c
+++ b/vl.c
@@ -534,7 +534,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_DEBUG, RUN_STATE_RUNNING },
 
     { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
-    { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
+    { RUN_STATE_INMIGRATE, RUN_STATE_PRELAUNCH_MIGRATE },
 
     { RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
     { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
@@ -580,6 +580,8 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
     { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
 
+    { RUN_STATE_PRELAUNCH_MIGRATE, RUN_STATE_RUNNING },
+
     { RUN_STATE_MAX, RUN_STATE_MAX },
 };
 
-- 
1.7.1

Re: [Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

On 03/07/2013 01:23 AM, Jason Wang wrote:
> Sometimes, we need track the state when guest is just about to start after
> migration. There's not a accurate state available which do this accurately
> (consider qemu may started with -S in destination).

s/may/may be/

and yes, libvirt _always_ starts qemu with -S in the destination.

> 
> So this patch introduces a new state prelaunch-migrate which just tracks this
> state, it covers the case both w/ and w/o -S in destination. The first user of
> this is the support of doing announce by guest.
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  migration.c      |    3 +--
>  qapi-schema.json |    5 ++++-
>  vl.c             |    4 +++-
>  3 files changed, 8 insertions(+), 4 deletions(-)

I'm not sure if this patch will have any negative effects on existing
libvirt migration or state reporting; adding Jirka to cc.

> 
> diff --git a/migration.c b/migration.c
> index 11725ae..ecdf2c5 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -107,10 +107,9 @@ static void process_incoming_migration_co(void *opaque)
>      /* Make sure all file formats flush their mutable metadata */
>      bdrv_invalidate_cache_all();
>  
> +    runstate_set(RUN_STATE_PRELAUNCH_MIGRATE);
>      if (autostart) {
>          vm_start();
> -    } else {
> -        runstate_set(RUN_STATE_PAUSED);
>      }
>  }
>  
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 28b070f..baa6361 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -174,11 +174,14 @@
>  # @suspended: guest is suspended (ACPI S3)
>  #
>  # @watchdog: the watchdog action is configured to pause and has been triggered
> +#
> +# @migrate-prelaunch: migration is completed and QEMU were started with -S

s/were/was/

>  ##
>  { 'enum': 'RunState',
>    'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
>              'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
> -            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
> +            'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
> +            'prelaunch-migrate'] }
>  
>  ##
>  # @SnapshotInfo
> diff --git a/vl.c b/vl.c
> index c03edf1..5dd2e0e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -534,7 +534,7 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_DEBUG, RUN_STATE_RUNNING },
>  
>      { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
> -    { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
> +    { RUN_STATE_INMIGRATE, RUN_STATE_PRELAUNCH_MIGRATE },
>  
>      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
>      { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
> @@ -580,6 +580,8 @@ static const RunStateTransition runstate_transitions_def[] = {
>      { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING },
>      { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE },
>  
> +    { RUN_STATE_PRELAUNCH_MIGRATE, RUN_STATE_RUNNING },
> +
>      { RUN_STATE_MAX, RUN_STATE_MAX },
>  };
>  
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state

[Jiri Denemark]

On Thu, Mar 07, 2013 at 08:37:17 -0700, Eric Blake wrote:
> On 03/07/2013 01:23 AM, Jason Wang wrote:
> > Sometimes, we need track the state when guest is just about to start after
> > migration. There's not a accurate state available which do this accurately
> > (consider qemu may started with -S in destination).
> 
> s/may/may be/
> 
> and yes, libvirt _always_ starts qemu with -S in the destination.
> 
> > 
> > So this patch introduces a new state prelaunch-migrate which just tracks this
> > state, it covers the case both w/ and w/o -S in destination. The first user of
> > this is the support of doing announce by guest.
> > 
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> >  migration.c      |    3 +--
> >  qapi-schema.json |    5 ++++-
> >  vl.c             |    4 +++-
> >  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> I'm not sure if this patch will have any negative effects on existing
> libvirt migration or state reporting; adding Jirka to cc.

I don't see any issues this patch could cause to libvirt. The only place
where we ask qemu for its current state is when we reconnect to existing
qemu processes after libvirtd restart. And the only thing we care about
is whether the guest is running or not. We use our own state information
to detect if we were migrating or not.

Jirka

Re: [Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state

[Jason Wang]

On 03/11/2013 10:31 PM, Jiri Denemark wrote:
> On Thu, Mar 07, 2013 at 08:37:17 -0700, Eric Blake wrote:
>> On 03/07/2013 01:23 AM, Jason Wang wrote:
>>> Sometimes, we need track the state when guest is just about to start after
>>> migration. There's not a accurate state available which do this accurately
>>> (consider qemu may started with -S in destination).
>> s/may/may be/
>>
>> and yes, libvirt _always_ starts qemu with -S in the destination.
>>
>>> So this patch introduces a new state prelaunch-migrate which just tracks this
>>> state, it covers the case both w/ and w/o -S in destination. The first user of
>>> this is the support of doing announce by guest.
>>>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>> ---
>>>  migration.c      |    3 +--
>>>  qapi-schema.json |    5 ++++-
>>>  vl.c             |    4 +++-
>>>  3 files changed, 8 insertions(+), 4 deletions(-)
>> I'm not sure if this patch will have any negative effects on existing
>> libvirt migration or state reporting; adding Jirka to cc.
> I don't see any issues this patch could cause to libvirt. The only place
> where we ask qemu for its current state is when we reconnect to existing
> qemu processes after libvirtd restart. And the only thing we care about
> is whether the guest is running or not. We use our own state information
> to detect if we were migrating or not.
>
> Jirka
>

Thanks for the checking. Since Michael prefers a device specific method
instead of introducing a new runstate, I plan to use post load and vm
state change handler instead of this new runstate in next version.

[Qemu-devel] [PATCH V7 2/5] net: announce self after vm is started

[Jason Wang]

Since we may want to send garp by guest if guest driver is capable of it. We
need trigger this event after vm is started. So this patch do this when the
state is changing from RUN_STATE_PRELAUNCH_MIGRATE to RUN_STATE_RUNINNG.

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 migration.c |    1 -
 vl.c        |    4 ++++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/migration.c b/migration.c
index ecdf2c5..3599d2d 100644
--- a/migration.c
+++ b/migration.c
@@ -100,7 +100,6 @@ static void process_incoming_migration_co(void *opaque)
         fprintf(stderr, "load of migration failed\n");
         exit(0);
     }
-    qemu_announce_self();
     DPRINTF("successfully loaded vm state\n");
 
     bdrv_clear_incoming_migration_all();
diff --git a/vl.c b/vl.c
index 5dd2e0e..ccf6ea7 100644
--- a/vl.c
+++ b/vl.c
@@ -1681,11 +1681,15 @@ void vm_state_notify(int running, RunState state)
 void vm_start(void)
 {
     if (!runstate_is_running()) {
+        RunState prev_run_state = current_run_state;
         cpu_enable_ticks();
         runstate_set(RUN_STATE_RUNNING);
         vm_state_notify(1, RUN_STATE_RUNNING);
         resume_all_vcpus();
         monitor_protocol_event(QEVENT_RESUME, NULL);
+        if (prev_run_state == RUN_STATE_PRELAUNCH_MIGRATE) {
+            qemu_announce_self();
+        }
     }
 }
 
-- 
1.7.1

[Qemu-devel] [PATCH V7 3/5] net: model specific announcing support

[Jason Wang]

This patch introduces a function pointer in NetClientInfo which is called during
self announcement. With this, each kind of card can announce the link with a
model specific way. The old method is still kept for cards that have not
implemented this or old guest. The first user would be virtio-net.

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 include/net/net.h |    2 ++
 savevm.c          |    8 ++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/net/net.h b/include/net/net.h
index cb049a1..49031b4 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -44,6 +44,7 @@ typedef ssize_t (NetReceiveIOV)(NetClientState *, const struct iovec *, int);
 typedef void (NetCleanup) (NetClientState *);
 typedef void (LinkStatusChanged)(NetClientState *);
 typedef void (NetClientDestructor)(NetClientState *);
+typedef int (NetAnnounce)(NetClientState *);
 
 typedef struct NetClientInfo {
     NetClientOptionsKind type;
@@ -55,6 +56,7 @@ typedef struct NetClientInfo {
     NetCleanup *cleanup;
     LinkStatusChanged *link_status_changed;
     NetPoll *poll;
+    NetAnnounce *announce;
 } NetClientInfo;
 
 struct NetClientState {
diff --git a/savevm.c b/savevm.c
index a8a53ef..fd69e32 100644
--- a/savevm.c
+++ b/savevm.c
@@ -76,12 +76,16 @@ static int announce_self_create(uint8_t *buf,
 
 static void qemu_announce_self_iter(NICState *nic, void *opaque)
 {
+    NetClientState *nc = qemu_get_queue(nic);
+    NetAnnounce *announce = nc->info->announce;
     uint8_t buf[60];
     int len;
 
-    len = announce_self_create(buf, nic->conf->macaddr.a);
+    if (!announce || announce(nc)) {
+        len = announce_self_create(buf, nic->conf->macaddr.a);
 
-    qemu_send_packet_raw(qemu_get_queue(nic), buf, len);
+        qemu_send_packet_raw(qemu_get_queue(nic), buf, len);
+    }
 }
 
 
-- 
1.7.1

[Qemu-devel] [PATCH V7 4/5] virtio-net: notify guest to annouce itself

[Jason Wang]

It's hard to track all mac addresses and their configurations (e.g vlan) in
qemu. Without those information, it's impossible to build proper garp packet
after migration. The only possible solution to this is let guest ( who knew all
configurations) to do this.

So, this patch introduces a new rw config status bit of virtio-net,
VIRTIO_NET_S_ANNOUNCE which is used to notify guest to announce presence of its
link through config update interrupt. When gust have done the announcement, it
should ack the notification through VIRTIO_NET_CTRL_ANNOUNCE_ACK cmd. This
feature is negotiated by a new feature bit VIRTIO_NET_F_ANNOUNCE.

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 hw/virtio-net.c |   30 ++++++++++++++++++++++++++++++
 hw/virtio-net.h |   15 ++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletions(-)

diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 009f09e..278c42c 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -610,6 +610,18 @@ static int virtio_net_handle_mq(VirtIONet *n, uint8_t cmd,
 
     return VIRTIO_NET_OK;
 }
+
+static int virtio_net_handle_announce(VirtIONet *n, uint8_t cmd,
+                                      struct iovec *iov, unsigned int iov_cnt)
+{
+    if (cmd == VIRTIO_NET_CTRL_ANNOUNCE_ACK) {
+        n->status &= ~VIRTIO_NET_S_ANNOUNCE;
+        return VIRTIO_NET_OK;
+    } else {
+        return VIRTIO_NET_ERR;
+    }
+}
+
 static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIONet *n = to_virtio_net(vdev);
@@ -639,6 +651,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
             status = virtio_net_handle_mac(n, ctrl.cmd, iov, iov_cnt);
         } else if (ctrl.class == VIRTIO_NET_CTRL_VLAN) {
             status = virtio_net_handle_vlan_table(n, ctrl.cmd, iov, iov_cnt);
+        } else if (ctrl.class == VIRTIO_NET_CTRL_ANNOUNCE) {
+            status = virtio_net_handle_announce(n, ctrl.cmd, iov, iov_cnt);
         } else if (ctrl.class == VIRTIO_NET_CTRL_MQ) {
             status = virtio_net_handle_mq(n, ctrl.cmd, iov, iov_cnt);
         }
@@ -1275,6 +1289,21 @@ static void virtio_net_cleanup(NetClientState *nc)
     n->nic = NULL;
 }
 
+static int virtio_net_announce(NetClientState *nc)
+{
+    VirtIONet *n = qemu_get_nic_opaque(nc);
+
+    if (n->vdev.guest_features & (0x1 << VIRTIO_NET_F_GUEST_ANNOUNCE)
+        && n->vdev.guest_features & (0x1 << VIRTIO_NET_F_CTRL_VQ)
+        && virtio_net_started(n, n->vdev.status)) {
+        n->status |= VIRTIO_NET_S_ANNOUNCE;
+        virtio_notify_config(&n->vdev);
+        return 0;
+    }
+
+    return -1;
+}
+
 static NetClientInfo net_virtio_info = {
     .type = NET_CLIENT_OPTIONS_KIND_NIC,
     .size = sizeof(NICState),
@@ -1282,6 +1311,7 @@ static NetClientInfo net_virtio_info = {
     .receive = virtio_net_receive,
         .cleanup = virtio_net_cleanup,
     .link_status_changed = virtio_net_set_link_status,
+    .announce = virtio_net_announce,
 };
 
 static bool virtio_net_guest_notifier_pending(VirtIODevice *vdev, int idx)
diff --git a/hw/virtio-net.h b/hw/virtio-net.h
index e654c13..c0f3de5 100644
--- a/hw/virtio-net.h
+++ b/hw/virtio-net.h
@@ -43,12 +43,13 @@
 #define VIRTIO_NET_F_CTRL_RX    18      /* Control channel RX mode support */
 #define VIRTIO_NET_F_CTRL_VLAN  19      /* Control channel VLAN filtering */
 #define VIRTIO_NET_F_CTRL_RX_EXTRA 20   /* Extra RX mode control support */
+#define VIRTIO_NET_F_GUEST_ANNOUNCE 21  /* Guest can announce itself */
 #define VIRTIO_NET_F_MQ         22      /* Device supports Receive Flow
                                          * Steering */
-
 #define VIRTIO_NET_F_CTRL_MAC_ADDR   23 /* Set MAC address */
 
 #define VIRTIO_NET_S_LINK_UP    1       /* Link is up */
+#define VIRTIO_NET_S_ANNOUNCE   2       /* Announcement is needed */
 
 #define TX_TIMER_INTERVAL 150000 /* 150 us */
 
@@ -152,6 +153,17 @@ struct virtio_net_ctrl_mac {
  #define VIRTIO_NET_CTRL_VLAN_DEL             1
 
 /*
+ * Control link announce acknowledgement
+ *
+ * The command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
+ * driver has recevied the notification and device would clear the
+ * VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
+ * this command.
+ */
+#define VIRTIO_NET_CTRL_ANNOUNCE       3
+ #define VIRTIO_NET_CTRL_ANNOUNCE_ACK         0
+
+/*
  * Control Multiqueue
  *
  * The command VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
@@ -180,6 +192,7 @@ struct virtio_net_ctrl_mq {
         DEFINE_PROP_BIT("guest_tso6", _state, _field, VIRTIO_NET_F_GUEST_TSO6, true), \
         DEFINE_PROP_BIT("guest_ecn", _state, _field, VIRTIO_NET_F_GUEST_ECN, true), \
         DEFINE_PROP_BIT("guest_ufo", _state, _field, VIRTIO_NET_F_GUEST_UFO, true), \
+        DEFINE_PROP_BIT("guest_announce", _state, _field, VIRTIO_NET_F_GUEST_ANNOUNCE, true), \
         DEFINE_PROP_BIT("host_tso4", _state, _field, VIRTIO_NET_F_HOST_TSO4, true), \
         DEFINE_PROP_BIT("host_tso6", _state, _field, VIRTIO_NET_F_HOST_TSO6, true), \
         DEFINE_PROP_BIT("host_ecn", _state, _field, VIRTIO_NET_F_HOST_ECN, true), \
-- 
1.7.1

[Qemu-devel] [PATCH V7 5/5] virtio-net: compat guest announce

[Jason Wang]

Disable guest announce for pre-1.5.

Signed-off-by: Jason Wang <jasowang@redhat.com>
---
 hw/pc.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index f2c1b1c..2de7cd4 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -221,6 +221,10 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
             .property = "vectors",\
             /* DEV_NVECTORS_UNSPECIFIED as a uint32_t string */\
             .value    = stringify(0xFFFFFFFF),\
-	}
+        },{\
+            .driver   = "virtio-net-pci",       \
+            .property = "guest_announce", \
+            .value    = "off",            \
+        }
 
 #endif
-- 
1.7.1

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

[Michael S. Tsirkin]

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?

> 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?

> - 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(-)

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

[Jason Wang]

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, and then maybe we can just do this
unconditionally in vm_start().
>> - 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(-)

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(-)

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

[Jason Wang]

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.
>> 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?

If we do this, there's no need to introduce a new state then.
>
> Can we do this simply using a post load hook for now?

Maybe not, this means we may want to inject an interrupt to guest when
vm is not running.
>>>> - 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(-)

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

[Michael S. Tsirkin]

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.

> >> 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?
> 
> If we do this, there's no need to introduce a new state then.
> >
> > Can we do this simply using a post load hook for now?
> 
> Maybe not, this means we may want to inject an interrupt to guest when
> vm is not running.

What I'm suggesting is basically:
- set some per device flag on load
- announce based on vmstart if flag is set

We can drop the flag later if we want it on every vmstart.

> >>>> - 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(-)

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

[Jason Wang]

On 03/07/2013 06:52 PM, 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.
>
>>>> 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?
>> If we do this, there's no need to introduce a new state then.
>>> Can we do this simply using a post load hook for now?
>> Maybe not, this means we may want to inject an interrupt to guest when
>> vm is not running.
> What I'm suggesting is basically:
> - set some per device flag on load
> - announce based on vmstart if flag is set

The only difference is how to figure out the correct time to do the
announcement. My proposal is using a global runstate  but yours is using
both device specific method and global changes (and may also lead the
garp to be sent after loadvm).
> We can drop the flag later if we want it on every vmstart.

If we want it on every vmstart, we can just register per-deivce vmstate
change handler to do this.
>
>>>>>> - 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(-)

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

[Stefan Hajnoczi]

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

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

[Jason Wang]

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.

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

[Liuyongan]

Hi,
	Has anybody here work on this subject and update a newer patch?
    Thanks in advance.

Yongan Liu


-----bellows are words from patch v7 ----
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.

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

[Jason Wang]

----- Original Message -----
> Hi,
> 	Has anybody here work on this subject and update a newer patch?
>     Thanks in advance.
> 
> Yongan Liu
> 
> 

Hi, I will continue work on this.

Just FYI, based on the discussions on past version, I plan to send a v8 just for virtio-net.

Thanks
> -----bellows are words from patch v7 ----
> 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.
> 
>