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 2D9346A8B for ; Wed, 10 Dec 2014 03:07:34 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 09 Dec 2014 18:07:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="645189401" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by fmsmga002.fm.intel.com with ESMTP; 09 Dec 2014 18:07:25 -0800 Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 10:06:06 +0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Dec 2014 10:06:06 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 10:06:04 +0800 From: "Qiu, Michael" To: "Xie, Huawei" , "Burakov, Anatoly" , "dev@dpdk.org" Thread-Topic: [PATCH v4] VFIO: Avoid to enable vfio while the module not loaded Thread-Index: AQHQEtP6ZMwNLWXWi0itz3mhbqdhBA== Date: Wed, 10 Dec 2014 02:06:03 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286C9E44C@SHSMSX101.ccr.corp.intel.com> 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> 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 02:07:36 -0000 On 12/10/2014 8:17 AM, Xie, Huawei wrote:=0A= > Hi Michael:=0A= >=0A= >> -----Original Message-----=0A= >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiu, Michael=0A= >> Sent: Monday, December 08, 2014 8:28 AM=0A= >> To: Burakov, Anatoly; dev@dpdk.org=0A= >> Subject: Re: [dpdk-dev] [PATCH v4] VFIO: Avoid to enable vfio while the = module=0A= >> not loaded=0A= >>=0A= >> On 2014/12/8 20:19, Burakov, Anatoly wrote:=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 mor= e=0A= >>>> soomth to user.=0A= >>>>=0A= >>>> Signed-off-by: Michael Qiu =0A= >>>> ---=0A= >>>> v4 --> v3:=0A= >>>> 1. Remove RTE_LOG for params check=0A= >>>> 2. Remove "vfio" module check as "vfio_iommu_type1"=0A= >>>> loaded indecated "vfio" loaded=0A= >>>>=0A= >>>> v3 --> v2:=0A= >>>> 1. Add error log in rte_eal_check_module()=0A= >>>> 2. Some code clean up.=0A= >>>>=0A= >>>> v2 --> v1:=0A= >>>> 1. Move check_module() from rte_common.h to eal_private.h=0A= >>>> and rename to rte_eal_check_module().=0A= >>>> To make it linuxapp only.=0A= >>>> 2. Some code clean up.=0A= >>>>=0A= >>>> lib/librte_eal/common/eal_private.h | 42=0A= >>>> ++++++++++++++++++++++++++++++=0A= >>>> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 29 ++++++++++++++++++---= =0A= >>>> 2 files changed, 68 insertions(+), 3 deletions(-)=0A= >>>>=0A= >>>> diff --git a/lib/librte_eal/common/eal_private.h=0A= >>>> b/lib/librte_eal/common/eal_private.h=0A= >>>> index 232fcec..e877a25 100644=0A= >>>> --- a/lib/librte_eal/common/eal_private.h=0A= >>>> +++ b/lib/librte_eal/common/eal_private.h=0A= >>>> @@ -35,6 +35,9 @@=0A= >>>> #define _EAL_PRIVATE_H_=0A= >>>>=0A= >>>> #include =0A= >>>> +#include =0A= >>>> +#include =0A= >>>> +#include =0A= >>>>=0A= >>>> /**=0A= >>>> * Initialize the memzone subsystem (private to eal).=0A= >>>> @@ -203,4 +206,43 @@ int rte_eal_alarm_init(void);=0A= >>>> */=0A= >>>> int rte_eal_dev_init(void);=0A= >>>>=0A= >>>> +/**=0A= >>>> + * Function is to check if the kernel module(like, vfio,=0A= >>>> +vfio_iommu_type1,=0A= >>>> + * etc.) loaded.=0A= >>>> + *=0A= >>>> + * @param module_name=0A= >>>> + * The module's name which need to be checked=0A= >>>> + *=0A= >>>> + * @return=0A= >>>> + * -1 means some error happens(NULL pointer or open failure)=0A= >>>> + * 0 means the module not loaded=0A= >>>> + * 1 means the module loaded=0A= >>>> + */=0A= >>>> +static inline int=0A= >>>> +rte_eal_check_module(const char *module_name) {=0A= >>>> + char mod_name[30]; /* Any module names can be longer than 30=0A= >>>> bytes? */=0A= >>>> + int ret =3D 0;=0A= >>>> +=0A= >>>> + if (NULL =3D=3D module_name)=0A= >>>> + return -1;=0A= >>>> +=0A= >>>> + FILE * fd =3D fopen("/proc/modules", "r");=0A= >>>> + if (NULL =3D=3D fd) {=0A= >>>> + RTE_LOG(ERR, EAL, "Open /proc/modules failed!"=0A= >>>> + " error %i (%s)\n", errno, strerror(errno));=0A= >>>> + return -1;=0A= >>>> + }=0A= >>>> + while(!feof(fd)) {=0A= >>>> + fscanf(fd, "%s %*[^\n]", mod_name);=0A= > I see it is already discussed in the other mail that we could limit the c= ount to avoid overflow.=0A= > I don't understand why you don't apply it here.=0A= =0A= =0A= Yes, I have reply in this thread with below:=0A= fscanf(fd, "%30s %*[^\n]", mod_name);=0A= =0A= > There are already several existing modules that has 20+ length. =0A= =0A= Yes, would you think 30 length is enough? Otherwise I need to increase=0A= the length=0A= =0A= Thanks,=0A= Michael=0A= >>>> + if(!strcmp(mod_name, module_name)) {=0A= >>>> + ret =3D 1;=0A= >>>> + break;=0A= >>>> + }=0A= >>>> + }=0A= >>>> + fclose(fd);=0A= >>>> +=0A= >>>> + return ret;=0A= >>>> +}=0A= >>>> +=0A= >>> Apologies for not bringing this up before, but do we really want the=0A= >> rte_eal_check_module inline in the header? I think it would be better to= declare=0A= >> it in eal_private but move the definition into eal.c.=0A= >>=0A= >> No need, actually, I'm very appreciate that you can spend your time to= =0A= >> review my patch again and again. I really want to say thank you to you.= =0A= >>=0A= >> For rte_eal_check_module inline in the header, it really no need stay in= =0A= >> header, so ugly. I will make new version of it, and re-post.=0A= >>=0A= >>=0A= >>>> #endif /* _EAL_PRIVATE_H_ */=0A= >>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c=0A= >>>> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c=0A= >>>> index c1246e8..8c54d2a 100644=0A= >>>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c=0A= >>>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c=0A= >>>> @@ -44,6 +44,7 @@=0A= >>>> #include =0A= >>>> #include =0A= >>>> #include =0A= >>>> +#include =0A= >>>>=0A= >>>> #include "eal_filesystem.h"=0A= >>>> #include "eal_pci_init.h"=0A= >>>> @@ -339,10 +340,15 @@ pci_vfio_get_container_fd(void)=0A= >>>> ret =3D ioctl(vfio_container_fd, VFIO_CHECK_EXTENSION,=0A= >>>> VFIO_TYPE1_IOMMU);=0A= >>>> if (ret !=3D 1) {=0A= >>>> if (ret < 0)=0A= >>>> - RTE_LOG(ERR, EAL, " could not get IOMMU=0A= >>>> type, "=0A= >>>> - "error %i (%s)\n", errno,=0A= >>>> strerror(errno));=0A= >>>> + RTE_LOG(ERR, EAL, " could not get IOMMU=0A= >>>> type,"=0A= >>>> + " error %i (%s)\n", errno,=0A= >>>> + strerror(errno));=0A= >>>> else=0A= >>>> - RTE_LOG(ERR, EAL, " unsupported IOMMU=0A= >>>> type!\n");=0A= >>>> + /* Better to show the IOMMU type return=0A= >>>> from=0A= >>>> + * kernel for easy debug=0A= >>>> + */=0A= >>>> + RTE_LOG(ERR, EAL, " unsupported IOMMU=0A= >>>> type"=0A= >>>> + " detected: %d in VFIO\n", ret);=0A= >>> I'm not sure this message is meaningful. That ioctl call can either -1,= 0 or 1. We=0A= >> already handle 1 separately; -1 means an error; 0 means IOMMU type 1 is = not=0A= >> supported. The return value will *not* indicate which IOMMU types *are*= =0A= >> currently supported - it will only indicate that the IOMMU type you requ= ested is=0A= >> not supported. So there's really no point in indicating the return value= in case of=0A= >> ret 0 - it is best to just mention that requested IOMMU type support is = not=0A= >> enabled in VFIO.=0A= >>=0A= >> Yes, you are right, I make a mistake.=0A= >>=0A= >>>> close(vfio_container_fd);=0A= >>>> return -1;=0A= >>>> }=0A= >>>> @@ -783,11 +789,28 @@ pci_vfio_enable(void) {=0A= >>>> /* initialize group list */=0A= >>>> int i;=0A= >>>> + int module_vfio_type1;=0A= >>>>=0A= >>>> for (i =3D 0; i < VFIO_MAX_GROUPS; i++) {=0A= >>>> vfio_cfg.vfio_groups[i].fd =3D -1;=0A= >>>> vfio_cfg.vfio_groups[i].group_no =3D -1;=0A= >>>> }=0A= >>>> +=0A= >>>> + module_vfio_type1 =3D rte_eal_check_module("vfio_iommu_type1");=0A= >>>> +=0A= >>>> + /* return error directly */=0A= >>>> + if (module_vfio_type1 =3D=3D -1) {=0A= >>>> + RTE_LOG(INFO, EAL, "Could not get loaded module=0A= >>>> details!\n");=0A= >>>> + return -1;=0A= >>>> + }=0A= >>>> +=0A= >>>> + /* return 0 if VFIO modules not loaded */=0A= >>>> + if (module_vfio_type1 =3D=3D 0) {=0A= >>>> + RTE_LOG(INFO, EAL, "VFIO modules not all loaded,"=0A= >>>> + " skip VFIO support ...\n");=0A= >>>> + return 0;=0A= >>>> + }=0A= >>>> +=0A= >>>> vfio_cfg.vfio_container_fd =3D pci_vfio_get_container_fd();=0A= >>>>=0A= >>>> /* check if we have VFIO driver enabled */=0A= >>>> --=0A= >>>> 1.9.3=0A= >=0A= =0A=