On Thu, Jun 11, 2015 at 02:10:48PM +0200, Thibaut Collet wrote: > I am not sure to understand your remark: > > > It needs to be sent when backend is activated by guest kick > > (in case of virtio 1, it's possible to use DRIVER_OK for this). > > This does not happen when VM still runs on source. > > Could you confirm rarp can be sent by backend when the > VHOST_USER_SET_VRING_KICK message is received by the backend ?
No - the time to send pakets is when you start processing the rings. And the time to do that is when you detect a kick on an eventfd, not when said fd is set. > At this time the migration is completed and there is no risk of confusing the > switch. > In this case: > - there are nothing to do in QEMU to manage legacy guest with > no GUEST_ANNOUNCE. > - All the job is done by the backend on the VHOST_USER_SET_VRING_KICK > reception. Maybe switch notification of live migration is done with a small > delay but it works > - This patch can be discarded. > > > On Thu, Jun 11, 2015 at 12:38 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > > On Thu, Jun 11, 2015 at 01:54:22PM +0800, Jason Wang wrote: > > > > > > On 06/11/2015 01:49 PM, Thibaut Collet wrote: > > > > Yes, but still need a mechanism to notify the backend of migration > > > > completion from qemu side if GUEST_ANNOUNCE is not negotiated. > > > > > > backend is aware of a connection with the guest (with the feature > > > negociation) and can send a rarp. This rarp will be always sent by the > > > backend when a VM is launched (first start or live migration > > > completion) if the GUEST_ANOUNCE is not supported. > > > In this case the issue is solved without done everything by QEMU. > > > > The issue is during migration guest network is still active. So sending > > rarp too early in the destination (e.g during VM is launched) may > > confuse the switch. We want it to be sent exactly when the migration is > > completed in destination. > > It needs to be sent when backend is activated by guest kick > (in case of virtio 1, it's possible to use DRIVER_OK for this). > This does not happen when VM still runs on source. > > > > If sending a rarp message on the start of te VM is not accceptable, we > > > must provide a mechanism similar of the one I have implemented. The > > > message content can be empty as the backend is able to create the rarp > > > message. > > > > Yes. > >
