Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

[Thibaut Collet]

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 ?

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 <address@hidden> 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.