From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CCAA68032 for ; Thu, 4 Dec 2014 14:47:14 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 04 Dec 2014 05:47:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="425035865" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by FMSMGA003.fm.intel.com with ESMTP; 04 Dec 2014 05:36:53 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 21:47:11 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 21:47:09 +0800 From: "Qiu, Michael" To: "Burakov, Anatoly" , Michael Qiu , "dev@dpdk.org" Thread-Topic: [PATCH] VFIO: Avoid to enable vfio while the module not loaded Thread-Index: AQHQD8G6SQyqYdhz8kSLOFnIk6ncxw== Date: Thu, 4 Dec 2014 13:47:09 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286C9CCC1@SHSMSX101.ccr.corp.intel.com> References: <1417664219-19679-1-git-send-email-michael.qiu@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] VFIO: Avoid to enable vfio while the module not loaded 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: Thu, 04 Dec 2014 13:47:15 -0000 On 12/4/2014 9:12 PM, Burakov, Anatoly wrote:=0A= > Hi Michael=0A= >=0A= >> When vfio module is not loaded when kernel support vfio feature, the=0A= >> routine still try to open the container to get file description.=0A= >>=0A= >> This action is not safe, and of cause got error messages:=0A= >>=0A= >> EAL: Detected 40 lcore(s)=0A= >> EAL: unsupported IOMMU type!=0A= >> EAL: VFIO support could not be initialized=0A= >> EAL: Setting up memory...=0A= >>=0A= >> This may make user confuse, this patch make it reasonable and much more= =0A= >> soomth to user.=0A= > Not sure I agree with the premise of this patch.=0A= >=0A= > First of all, if VFIO driver is not enabled, the container file would not= be present and you would get a different error (namely, "cannot open VFIO = container", in pci_vfio_get_container_fd()). If you have a container file, = that means VFIO driver is loaded, so I'm not sure why you get the "unsuppo= rted IOMMU type" error. I suppose it could happen when vfio is loaded but v= fio_iommu_type1 isn't?=0A= =0A= But indeed, when try to unload both vfio and vfio_iommu_type1,=0A= /dev/vfio/vfio still there, I'm also surprise.=0A= =0A= My ENV is fedora20, kernel version 3.6.7-200 X86_64.=0A= =0A= Believe or not, you can have a try, it seems a kernel issue.=0A= =0A= When you unload both two modules, then open /dev/vfio/vfio, you will=0A= find it can be opened with no errors(but this time both two modules=0A= loaded automatically, strange enough)=0A= =0A= Also you can use ioctl to get API Version. But when you try to get the=0A= iommu type, it will return a "0" not expect value of '1'.=0A= =0A= Then you can shutdown DPDK, reopen like test-pmd, all works fine :)=0A= =0A= I will take a deep look at in the kernel side, to find out why this happens= .=0A= =0A= Thanks,=0A= Michael=0A= > And even then, this error is harmless and doesn't do anything, so I'm not= sure what this patch is supposed to fix. The error messages tells the user= exactly what happens.=0A= > =0A= > Thanks,=0A= > Anatoly =0A= >=0A= =0A=