From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4A5B5AFD1 for ; Tue, 17 Jun 2014 18:29:00 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 17 Jun 2014 09:23:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,495,1400050800"; d="log'?scan'208";a="529911050" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 17 Jun 2014 09:28:43 -0700 Received: from irsmsx105.ger.corp.intel.com (163.33.3.28) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Jun 2014 17:28:43 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.58]) by IRSMSX105.ger.corp.intel.com ([169.254.7.239]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 17:28:42 +0100 From: "Richardson, Bruce" To: "Burakov, Anatoly" , "dev@dpdk.org" Thread-Topic: vfio detection Thread-Index: Ac+Jr+QsX/7njye/SDa+CSH3FJFocAAVxw1QABBHEgA= Date: Tue, 17 Jun 2014 16:28:41 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B01AA370A7@IRSMSX103.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B01AA36B6E@IRSMSX103.ger.corp.intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] vfio detection 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, 17 Jun 2014 16:29:04 -0000 > -----Original Message----- > From: Burakov, Anatoly > Sent: Tuesday, June 17, 2014 1:40 AM > To: Richardson, Bruce; dev@dpdk.org > Subject: RE: vfio detection >=20 > Hi Bruce, >=20 > > I have a number of NIC ports which were working correctly yesterday and= are > > bound correctly to the igb_uio driver - and I want to keep using them > > through the igb_uio driver for now, not vfio. However, whenever I run a > > dpdk application today, I find that the vfio kernel module is getting l= oaded > > each time - even after I manually remove it, and verify that it has bee= n > > removed by checking lsmod. Is this expected? If so, why are we loading = the > > vfio driver when I just want to continue using igb_uio which works fine= ? >=20 > Can you elaborate a bit on what do you mean by "loading vfio driver"? Do = you > mean the vfio-pci kernel gets loaded by DPDK? I certainly didn't put in a= ny code > that would automatically load that driver, and certainly not binding devi= ces to it. The kernel module called just "vfio" is constantly getting reloaded, and th= ere is always a "/dev/vfio" directory, which triggers the vfio code handlin= g every time I run dpdk. >=20 > > Secondly, then, when testpmd or any other app loads, it automatically t= ries > > to map the NIC using vfio and then aborts on the very first NIC port wh= en it > > fails to do so. >=20 > This shouldn't happen, unless you have a device bound to VFIO and have an= other > device in the same IOMMU group that is bound to something else. Can you > provide a log of what you are seeing? Log of testpmd run attached. >=20 > > This a) prevents the port from being mapped using igb_uio, and > > b) for ports which are meant to stay under linux control, forces me to = start > > enumerating ports using blacklist or whitelisting, rather than having t= hings > > "just work" on a properly configured system as before, i.e. if a port i= s bound > > to igb_uio or vfio it is used, if not bound, it is ignored. Again, is t= his by design > > and expected, because it seems a major regression in usability? >=20 > I think automatic port unbinding and binding was removed, so this again > shouldn't happen at all. >=20 > It would be useful to have logs for all of these described situations, be= cause we > certainly didn't encounter any of that during the validation cycle. >=20 Log of testpmd run attached. If you need any more debugging info, let me kn= ow. I'll also test out the patch you just posted to the list - see if it makes = any difference, and I'll send on a log from it. /Bruce