From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by dpdk.org (Postfix) with ESMTP id 7DEBFB109 for ; Wed, 18 Jun 2014 15:07:44 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 18 Jun 2014 06:07:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,499,1400050800"; d="scan'208";a="447013408" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by azsmga001.ch.intel.com with ESMTP; 18 Jun 2014 06:07:20 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id s5ID7KxP022444; Wed, 18 Jun 2014 14:07:20 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id s5ID7Krg031987; Wed, 18 Jun 2014 14:07:20 +0100 Received: (from aburakov@localhost) by sivswdev01.ir.intel.com with id s5ID7KsX031982; Wed, 18 Jun 2014 14:07:20 +0100 From: Anatoly Burakov To: dev@dpdk.org Date: Wed, 18 Jun 2014 14:07:18 +0100 Message-Id: <299e8046266266ad6faa1a01e6d719407dcbda67.1403096022.git.anatoly.burakov@intel.com> X-Mailer: git-send-email 1.7.0.7 In-Reply-To: <4bf447650cc99e316e6427e3a1c134dd417af4ec.1402996488.git.anatoly.burakov@intel.com> References: <4bf447650cc99e316e6427e3a1c134dd417af4ec.1402996488.git.anatoly.burakov@intel.com> In-Reply-To: References: Subject: [dpdk-dev] [PATCH v2 1/2] vfio: open VFIO container at startup rather than during init 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, 18 Jun 2014 13:07:45 -0000 Currently, VFIO only checks for being able to access the /dev/vfio directory when initializing VFIO, deferring actual VFIO container initialization to VFIO binding code. This doesn't bode well for when VFIO container cannot be initialized for whatever reason, because it results in unrecoverable error even if the user didn't set up VFIO and didn't even want to use it in the first place. This patch fixes this by moving container initialization into the code that checks if VFIO is available at runtime. Therefore, any issues with the container will be known at initialization stage and VFIO will simply be turned off if container could not be set up. Signed-off-by: Anatoly Burakov Acked-by: Bruce Richardson --- lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c index 4de6061..9eb5dcd 100644 --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c @@ -523,17 +523,6 @@ pci_vfio_map_resource(struct rte_pci_device *dev) rte_snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT, loc->domain, loc->bus, loc->devid, loc->function); - /* get container fd (needs to be done only once per initialization) */ - if (vfio_cfg.vfio_container_fd == -1) { - int vfio_container_fd = pci_vfio_get_container_fd(); - if (vfio_container_fd < 0) { - RTE_LOG(ERR, EAL, " %s cannot open VFIO container!\n", pci_addr); - return -1; - } - - vfio_cfg.vfio_container_fd = vfio_container_fd; - } - /* get group number */ iommu_group_no = pci_vfio_get_group_no(pci_addr); @@ -770,10 +759,10 @@ pci_vfio_enable(void) vfio_cfg.vfio_groups[i].fd = -1; vfio_cfg.vfio_groups[i].group_no = -1; } - vfio_cfg.vfio_container_fd = -1; + vfio_cfg.vfio_container_fd = pci_vfio_get_container_fd(); /* check if we have VFIO driver enabled */ - if (access(VFIO_DIR, F_OK) == 0) + if (vfio_cfg.vfio_container_fd != -1) vfio_cfg.vfio_enabled = 1; else RTE_LOG(INFO, EAL, "VFIO driver not loaded or wrong permissions\n"); -- 1.8.1.4