From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B43945A4D for ; Tue, 15 Dec 2015 14:59:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 15 Dec 2015 05:59:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,432,1444719600"; d="scan'208";a="618336671" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 15 Dec 2015 05:59:04 -0800 Date: Tue, 15 Dec 2015 21:59:07 +0800 From: Yuanhan Liu To: Pavel Fedin Message-ID: <20151215135907.GK29571@yliu-dev.sh.intel.com> References: <001c01d133fd$d3a7d870$7af78950$@samsung.com> <20151214035842.GB18437@pxdev.xzpeter.org> <20151215082324.GG29571@yliu-dev.sh.intel.com> <007f01d13715$042a0a80$0c7e1f80$@samsung.com> <20151215100548.GD32243@pxdev.xzpeter.org> <00b601d13733$97e063a0$c7a12ae0$@samsung.com> <20151215133612.GJ29571@yliu-dev.sh.intel.com> <00ca01d1373f$3dd4ab30$b97e0190$@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ca01d1373f$3dd4ab30$b97e0190$@samsung.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org, 'Victor Kaplansky' Subject: Re: [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:59:07 -0000 On Tue, Dec 15, 2015 at 04:48:12PM +0300, Pavel Fedin wrote: > Hello! > > > > Wrong. I tried to unconditionally enforce it in qemu (my guest does support it), and the > > link stopped working at all. I don't understand why. > > > > I'm wondering how did you do that? Why do you need enforece it in QEMU? > > Isn't it already supported so far? > > I mean - qemu first asks vhost-user server (ovs/DPDK in our case) about capabilities, then negotiates them with the guest. And DPDK > doesn't report VIRTIO_NET_F_GUEST_ANNOUNCE, so i just ORed this flag in qemu before the negotiation with guest (because indeed my > logic says that the host should not do anything special about it). So the overall effect is the same as in your patch I see. > > > diff --git a/lib/librte_vhost/virtio-net.c > > b/lib/librte_vhost/virtio-net.c > > index 03044f6..0ba5045 100644 > > --- a/lib/librte_vhost/virtio-net.c > > +++ b/lib/librte_vhost/virtio-net.c > > @@ -74,6 +74,7 @@ static struct virtio_net_config_ll *ll_root; > > #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \ > > (1ULL << VIRTIO_NET_F_CTRL_VQ) | \ > > (1ULL << VIRTIO_NET_F_CTRL_RX) | \ > > + (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \ > > (VHOST_SUPPORTS_MQ) | \ > > (1ULL << VIRTIO_F_VERSION_1) | \ > > (1ULL << VHOST_F_LOG_ALL) | \ > > But i was somehow wrong and this causes the whole thing to stop working instead. Even after just booting up the network doesn't > work and PINGs do not pass. No idea. Maybe you have changed some other configures (such as of ovs) without notice? Or, the ovs bridge interface resets? BTW, would you please try my v1 patch set with above diff applied to see if the ping loss is still there. You might also want to run tcpdump with the dest host ovs bridge, to see if GARP is actually sent. > > > However, I found the GARP is not sent out at all, due to an error > > I met and reported before: > > > > KVM: injection failed, MSI lost (Operation not permitted) I was thinking that may be caused by the difference of my two hosts (a desktop and a server). I will try to find two similar hosts tomorrow to do more tests. Besides that, it'd be great if you could do a more test with above diff applied. --yliu > > Interesting, i don't have this problem here. Some bug in your kernel/hardware? > > > One thing worth noting is that it happened only when I did live migration > > on two different hosts (the two hosts happened to be using a same old > > kernel: v3.11.10). It works pretty well on same host. So, seems like > > a KVM bug then? > > 3.18.9 here and no this problem. > > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia >