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

[Thibaut Collet]

Ok.

backend is able to know when the eventfd is kick the first time and then can send a rarp for legacy guest.

With this backend modification the issue point by Jason is no more a QEMU problem.

Full support of live migration for vhost user:

 - Need my first patch.

 - For legacy guest the backend must be updated to send a rarp when the eventfd is kick the first time.

To summarize the status:

1. The first patch must be updated by:

      - removing the warning trace

      - setting the error trace inside a static bool flag to only print this once

      - removing the vhost_net_inject_rarp function (no more useful)

2. The second patch must be removed. Management of legacy guest for rarp sending can be done by modifications in backend without any change in QEMU.

Does everyone agree with this summary?

On Thu, Jun 11, 2015 at 2:13 PM, Michael S. Tsirkin <address@hidden> wrote:

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