From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: Re: [PATCH 0/4 for 2.3] vhost-user live migration support Date: Tue, 15 Dec 2015 16:48:12 +0300 Message-ID: <00ca01d1373f$3dd4ab30$b97e0190$@samsung.com> References: <000001d133ed$b2446eb0$16cd4c10$@samsung.com> <20151211094934.GX29571@yliu-dev.sh.intel.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, 'Victor Kaplansky' To: 'Yuanhan Liu' Return-path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id BC2E311F5 for ; Tue, 15 Dec 2015 14:48:14 +0100 (CET) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NZE006SNJODP2B0@mailout1.w1.samsung.com> for dev@dpdk.org; Tue, 15 Dec 2015 13:48:13 +0000 (GMT) In-reply-to: <20151215133612.GJ29571@yliu-dev.sh.intel.com> Content-language: ru List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > 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. > 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) 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