From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id BC4E71B798; Fri, 13 Oct 2017 23:15:53 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6314E20AAF; Fri, 13 Oct 2017 17:15:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 13 Oct 2017 17:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=QGH/wVtbl6iW8PUcip/PTUkIOA o5s9CfRuOJvhAbiWc=; b=JXGpBwmANShskSrlWRWyuaxGxpy3JDUhMxfBqdAQu8 R4tJPZ0HvMHiNJ6+LcWsaKaP06LBC0uK7RXKaN+4v7vYsXn237AbEmipuB2yeJnd qRNs8CAnahffV9UWnaUUJGIYRuQbAwzn+WNJZR9JibyJ856XE0QBYFzPo+AMM9I1 E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QGH/wV tbl6iW8PUcip/PTUkIOAo5s9CfRuOJvhAbiWc=; b=OBgiplZt9rVmZfGKgILjQc sFwnb2F3EzP0XD6PKdNe2bOeH2uloMFQXJXOg/LTG3KxxOy75SE56eZ4yTcjt4SL NLabrExkYsPH/vAbD//GusUCmLZpqcKRu+irnAvRn0Ukl1sE4A6LvzDnwKcpBQby loXdhJx1aGUWT4/3vJnOFjLPQTSixDi/+m4QoMeCY5+/D0ZMIBU34e6sbmfzPUAT V6OH5IVxAG2T5pQN/Y9JgjDAFSVrj+NVvYLrgnENngSmO+ATvQLXe1VmMyx7EgaX Tok9ShERifpQiyRkQFaVi392VrSbVZA9tucNF+ydk9apkR8G4aSmNnBKsc9d8ikg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E8CF24737; Fri, 13 Oct 2017 17:15:53 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , harish.patil@cavium.com Cc: stable@dpdk.org, Jingjing Wu , jianfeng.tan@intel.com, shijith.thotton@caviumnetworks.com, gregory@weka.io, beilei.xing@intel.com, dev@dpdk.org Date: Fri, 13 Oct 2017 23:15:52 +0200 Message-ID: <26004513.65WVqXSdeM@xps> In-Reply-To: <95051c86-9088-19a7-99f8-27eb1d8b525c@intel.com> References: <1507581083-33667-1-git-send-email-jingjing.wu@intel.com> <1507581083-33667-2-git-send-email-jingjing.wu@intel.com> <95051c86-9088-19a7-99f8-27eb1d8b525c@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [PATCH 2/2] igb_uio: fix interrupt enablement after FLR in VM X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:15:54 -0000 13/10/2017 22:54, Ferruh Yigit: > On 10/9/2017 9:31 PM, Jingjing Wu wrote: > > If pass-through a VF by vfio-pci to a Qemu VM, after FLR > > in VM, the interrupt setting is not recoverd correctly > > to host as below: > > in VM guest: > > Capabilities: [70] MSI-X: Enable+ Count=5 Masked- > > in Host: > > Capabilities: [70] MSI-X: Enable+ Count=5 Masked- > > > > That was because in pci_reset_function, it first reads the > > PCI configure and set FLR reset, and then writes PCI configure > > as restoration. But not all the writing are successful to Host. > > Becuase vfio-pci driver doesn't allow directly write PCI MSI-X > > Cap. > > > > To fix this issue, we need to move the interrupt enablement from > > igb_uio probe to open device file. While is also the similar as > > the behaviour in vfio_pci kernel module code. > > So I guess this also explains why pci_reset in open() cause the problem, > when this is called for VF, interrupts stays disable for both VF and PF? > > > > > Fixes: b58eedfc7dd5 ("igb_uio: issue FLR during open and release of device file") > > > > Cc: stable@dpdk.org > > > > Signed-off-by: Jingjing Wu > > Signed-off-by: Jianfeng Tan > > Acked-by: Ferruh Yigit > > > We have two options, getting this patch or revert the original patch, > Thomas already has a patch for reverting. > > The original patch is to make igb_uio safer. To not leave device in > unwanted stated. Problem related to this has been reported a few times, > I believe it is good to fix this problem. And since we already have some > movement towards fix, I say lets continue instead of revert. > > Only problem is the scope of the patch is wide, and in previous release > it already break some uses cases, this is a little scary, please support > on testing this more. > > I suggest getting this fix for rc1 and let it to be tested properly, and > if we hit some problem, we can always revert and work on problem for > next release. OK, let's try. Harish, please help testing this patch with qede. Thanks