From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z31Js-00013A-KA for qemu-devel@nongnu.org; Thu, 11 Jun 2015 08:10:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z31Jp-0003aJ-B1 for qemu-devel@nongnu.org; Thu, 11 Jun 2015 08:10:52 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:35587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z31Jp-0003aF-5i for qemu-devel@nongnu.org; Thu, 11 Jun 2015 08:10:49 -0400 Received: by igbzc4 with SMTP id zc4so54639231igb.0 for ; Thu, 11 Jun 2015 05:10:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150611123433-mutt-send-email-mst@redhat.com> References: <1433943783-20125-1-git-send-email-thibaut.collet@6wind.com> <1433943783-20125-3-git-send-email-thibaut.collet@6wind.com> <20150610173321-mutt-send-email-mst@redhat.com> <20150610180013-mutt-send-email-mst@redhat.com> <55791F29.6060000@redhat.com> <5579228E.1040705@redhat.com> <20150611123433-mutt-send-email-mst@redhat.com> Date: Thu, 11 Jun 2015 14:10:48 +0200 Message-ID: From: Thibaut Collet Content-Type: multipart/alternative; boundary=001a11c30f9ec9279705183ce1dc Subject: Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Jason Wang , qemu-devel , Stefan Hajnoczi --001a11c30f9ec9279705183ce1dc Content-Type: text/plain; charset=UTF-8 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 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. > --001a11c30f9ec9279705183ce1dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not sure to understand your remark:

> It needs to b= e sent when backend is activated by guest kick
> (in case of virtio 1, it's p= ossible 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=C2=A0V= HOST_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:
=C2=A0 - there are nothing to do = in QEMU to manage legacy guest with no=C2=A0GUEST_ANNOUNCE.
=C2= =A0 - All the job is done by the backend on the VHOST_USER_SET_VRING_KICK r= eception. Maybe switch notification of live migration is done with a small = delay but it works
=C2=A0 - This patch can be discarded.


On Thu, Jun 11, 2015 at 12:38 PM, Michael S. Tsirkin <= ;mst@redhat.com>= wrote:
On Thu, J= un 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 mig= ration
> > > completion from qemu side if GUEST_ANNOUNCE is not negotiate= d.
> >
> > backend is aware of a connection with the guest (with the feature=
> > negociation) and can send a rarp. This rarp will be always sent b= y 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 sendin= g
> rarp too early in the destination (e.g during VM is launched) may
> confuse the switch.=C2=A0 We want it to be sent exactly when the migra= tion 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 accceptabl= e, we
> > must provide a mechanism similar of the one I have implemented. T= he
> > message content can be empty as the backend is able to create the= rarp
> > message.
>
> Yes.

--001a11c30f9ec9279705183ce1dc--