From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6F0452C47 for ; Fri, 26 Feb 2016 09:45:35 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 26 Feb 2016 00:45:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,498,1449561600"; d="scan'208";a="911705757" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga001.fm.intel.com with ESMTP; 26 Feb 2016 00:45:35 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 26 Feb 2016 00:45:33 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.42]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 16:44:41 +0800 From: "Xie, Huawei" To: David Marchand , Yuanhan Liu Thread-Topic: virtio PMD is not working with master version Thread-Index: AdFwce4S7CikSPHHRxesYIbCxeS1CA== Date: Fri, 26 Feb 2016 08:44:40 +0000 Message-ID: References: <20160226022358.GG14300@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] virtio PMD is not working with master version 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: Fri, 26 Feb 2016 08:45:36 -0000 On 2/26/2016 4:29 PM, David Marchand wrote:=0A= > On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu=0A= > wrote:=0A= >> Mauricio, thanks for the testing and report.=0A= >>=0A= >> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:=0A= >>> >From the logs, I would say I broke uio_pci_generic since we are in=0A= >>> "uio" case, but uio portio sysfs does not exist.=0A= >>> virtio pmd fell back to ioports discovery before my change.=0A= >> Maybe we can do same?=0A= We shouldn't, :). I am now rebasing the patch to fix the issue that=0A= virtio driver takes the virtio device blindly.=0A= With the patch:=0A= if driver is VFIO/UIO, and errors happens, returns without falling back=0A= to IO port.=0A= if no any kernel driver is managing the device, try IO port; otherwise=0A= returns 1 to tell the layer we don't take over this device.=0A= =0A= > I suppose, but see below.=0A= >=0A= >> ---=0A= >> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linu= xapp/eal/eal_pci.c=0A= >> index 4346973..579731c 100644=0A= >> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c=0A= >> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c=0A= >> @@ -685,12 +685,11 @@ int=0A= >> rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,=0A= >> struct rte_pci_ioport *p)=0A= >> {=0A= >> - int ret;=0A= >> + int ret =3D -1;=0A= >>=0A= >> switch (dev->kdrv) {=0A= >> #ifdef VFIO_PRESENT=0A= >> case RTE_KDRV_VFIO:=0A= >> - ret =3D -1;=0A= >> if (pci_vfio_is_enabled())=0A= >> ret =3D pci_vfio_ioport_map(dev, bar, p);=0A= >> break;=0A= >> @@ -700,14 +699,14 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev,= int bar,=0A= >> ret =3D pci_uio_ioport_map(dev, bar, p);=0A= >> break;=0A= >> default:=0A= >> + break;=0A= >> + }=0A= >> +=0A= >> #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)=0A= >> - /* special case for x86 ... */=0A= >> + /* special case for x86 ... */=0A= >> + if (ret)=0A= >> ret =3D pci_ioport_map(dev, bar, p);=0A= >> -#else=0A= >> - ret =3D -1;=0A= >> #endif=0A= >> - break;=0A= >> - }=0A= > What if we are supposed to do vfio here, but for some reason init failed = ?=0A= > Next thing, we will call ioport_read in vfio context, but init went=0A= > through the ioports parsing =3D> boom ?=0A= >=0A= > Another issue is that when device is bound to a kernel driver (let's=0A= > say virtio-pci here), then init will succeed and pmd will kick in the=0A= > device registers.=0A= >=0A= > This special case should really be narrowed down to "uio" and "none"=0A= > driver cases.=0A= >=0A= >=0A= =0A=