From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 406827E79 for ; Wed, 10 Dec 2014 01:17:11 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 09 Dec 2014 16:17:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="496342462" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by orsmga003.jf.intel.com with ESMTP; 09 Dec 2014 16:13:25 -0800 Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 08:17:03 +0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 08:17:02 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.67]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 08:17:01 +0800 From: "Xie, Huawei" To: "Qiu, Michael" , "Burakov, Anatoly" , "dev@dpdk.org" Thread-Topic: [PATCH v4] VFIO: Avoid to enable vfio while the module not loaded Thread-Index: AQHQEuGE5CZ3leqpc0upi6MiPP8BipyH9YQA Date: Wed, 10 Dec 2014 00:17:00 +0000 Message-ID: References: <1417687227-21854-1-git-send-email-michael.qiu@intel.com> <1418035455-9434-1-git-send-email-michael.qiu@intel.com> <533710CFB86FA344BFBF2D6802E60286C9DB9E@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <533710CFB86FA344BFBF2D6802E60286C9DB9E@SHSMSX101.ccr.corp.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 v4] 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: Wed, 10 Dec 2014 00:17:12 -0000 Hi Michael: > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiu, Michael > Sent: Monday, December 08, 2014 8:28 AM > To: Burakov, Anatoly; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] VFIO: Avoid to enable vfio while the m= odule > not loaded >=20 > On 2014/12/8 20:19, Burakov, Anatoly wrote: > >> When vfio module is not loaded when kernel support vfio feature, the > >> routine still try to open the container to get file description. > >> > >> This action is not safe, and of cause got error messages: > >> > >> EAL: Detected 40 lcore(s) > >> EAL: unsupported IOMMU type! > >> EAL: VFIO support could not be initialized > >> EAL: Setting up memory... > >> > >> This may make user confuse, this patch make it reasonable and much mor= e > >> soomth to user. > >> > >> Signed-off-by: Michael Qiu > >> --- > >> v4 --> v3: > >> 1. Remove RTE_LOG for params check > >> 2. Remove "vfio" module check as "vfio_iommu_type1" > >> loaded indecated "vfio" loaded > >> > >> v3 --> v2: > >> 1. Add error log in rte_eal_check_module() > >> 2. Some code clean up. > >> > >> v2 --> v1: > >> 1. Move check_module() from rte_common.h to eal_private.h > >> and rename to rte_eal_check_module(). > >> To make it linuxapp only. > >> 2. Some code clean up. > >> > >> lib/librte_eal/common/eal_private.h | 42 > >> ++++++++++++++++++++++++++++++ > >> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 29 ++++++++++++++++++--- > >> 2 files changed, 68 insertions(+), 3 deletions(-) > >> > >> diff --git a/lib/librte_eal/common/eal_private.h > >> b/lib/librte_eal/common/eal_private.h > >> index 232fcec..e877a25 100644 > >> --- a/lib/librte_eal/common/eal_private.h > >> +++ b/lib/librte_eal/common/eal_private.h > >> @@ -35,6 +35,9 @@ > >> #define _EAL_PRIVATE_H_ > >> > >> #include > >> +#include > >> +#include > >> +#include > >> > >> /** > >> * Initialize the memzone subsystem (private to eal). > >> @@ -203,4 +206,43 @@ int rte_eal_alarm_init(void); > >> */ > >> int rte_eal_dev_init(void); > >> > >> +/** > >> + * Function is to check if the kernel module(like, vfio, > >> +vfio_iommu_type1, > >> + * etc.) loaded. > >> + * > >> + * @param module_name > >> + * The module's name which need to be checked > >> + * > >> + * @return > >> + * -1 means some error happens(NULL pointer or open failure) > >> + * 0 means the module not loaded > >> + * 1 means the module loaded > >> + */ > >> +static inline int > >> +rte_eal_check_module(const char *module_name) { > >> + char mod_name[30]; /* Any module names can be longer than 30 > >> bytes? */ > >> + int ret =3D 0; > >> + > >> + if (NULL =3D=3D module_name) > >> + return -1; > >> + > >> + FILE * fd =3D fopen("/proc/modules", "r"); > >> + if (NULL =3D=3D fd) { > >> + RTE_LOG(ERR, EAL, "Open /proc/modules failed!" > >> + " error %i (%s)\n", errno, strerror(errno)); > >> + return -1; > >> + } > >> + while(!feof(fd)) { > >> + fscanf(fd, "%s %*[^\n]", mod_name); I see it is already discussed in the other mail that we could limit the cou= nt to avoid overflow. I don't understand why you don't apply it here. There are already several existing modules that has 20+ length.=20 > >> + if(!strcmp(mod_name, module_name)) { > >> + ret =3D 1; > >> + break; > >> + } > >> + } > >> + fclose(fd); > >> + > >> + return ret; > >> +} > >> + > > Apologies for not bringing this up before, but do we really want the > rte_eal_check_module inline in the header? I think it would be better to = declare > it in eal_private but move the definition into eal.c. >=20 > No need, actually, I'm very appreciate that you can spend your time to > review my patch again and again. I really want to say thank you to you. >=20 > For rte_eal_check_module inline in the header, it really no need stay in > header, so ugly. I will make new version of it, and re-post. >=20 >=20 > >> #endif /* _EAL_PRIVATE_H_ */ > >> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > >> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > >> index c1246e8..8c54d2a 100644 > >> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > >> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > >> @@ -44,6 +44,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include "eal_filesystem.h" > >> #include "eal_pci_init.h" > >> @@ -339,10 +340,15 @@ pci_vfio_get_container_fd(void) > >> ret =3D ioctl(vfio_container_fd, VFIO_CHECK_EXTENSION, > >> VFIO_TYPE1_IOMMU); > >> if (ret !=3D 1) { > >> if (ret < 0) > >> - RTE_LOG(ERR, EAL, " could not get IOMMU > >> type, " > >> - "error %i (%s)\n", errno, > >> strerror(errno)); > >> + RTE_LOG(ERR, EAL, " could not get IOMMU > >> type," > >> + " error %i (%s)\n", errno, > >> + strerror(errno)); > >> else > >> - RTE_LOG(ERR, EAL, " unsupported IOMMU > >> type!\n"); > >> + /* Better to show the IOMMU type return > >> from > >> + * kernel for easy debug > >> + */ > >> + RTE_LOG(ERR, EAL, " unsupported IOMMU > >> type" > >> + " detected: %d in VFIO\n", ret); > > I'm not sure this message is meaningful. That ioctl call can either -1,= 0 or 1. We > already handle 1 separately; -1 means an error; 0 means IOMMU type 1 is n= ot > supported. The return value will *not* indicate which IOMMU types *are* > currently supported - it will only indicate that the IOMMU type you reque= sted is > not supported. So there's really no point in indicating the return value = in case of > ret 0 - it is best to just mention that requested IOMMU type support is n= ot > enabled in VFIO. >=20 > Yes, you are right, I make a mistake. >=20 > > > >> close(vfio_container_fd); > >> return -1; > >> } > >> @@ -783,11 +789,28 @@ pci_vfio_enable(void) { > >> /* initialize group list */ > >> int i; > >> + int module_vfio_type1; > >> > >> for (i =3D 0; i < VFIO_MAX_GROUPS; i++) { > >> vfio_cfg.vfio_groups[i].fd =3D -1; > >> vfio_cfg.vfio_groups[i].group_no =3D -1; > >> } > >> + > >> + module_vfio_type1 =3D rte_eal_check_module("vfio_iommu_type1"); > >> + > >> + /* return error directly */ > >> + if (module_vfio_type1 =3D=3D -1) { > >> + RTE_LOG(INFO, EAL, "Could not get loaded module > >> details!\n"); > >> + return -1; > >> + } > >> + > >> + /* return 0 if VFIO modules not loaded */ > >> + if (module_vfio_type1 =3D=3D 0) { > >> + RTE_LOG(INFO, EAL, "VFIO modules not all loaded," > >> + " skip VFIO support ...\n"); > >> + return 0; > >> + } > >> + > >> vfio_cfg.vfio_container_fd =3D pci_vfio_get_container_fd(); > >> > >> /* check if we have VFIO driver enabled */ > >> -- > >> 1.9.3 > >