From patchwork Wed Nov 18 15:37:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Burakov, Anatoly" X-Patchwork-Id: 84329 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AD27DA04DD; Wed, 18 Nov 2020 16:38:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 04CF1C94E; Wed, 18 Nov 2020 16:37:53 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 875842AB for ; Wed, 18 Nov 2020 16:37:45 +0100 (CET) IronPort-SDR: +E9eS9rYZLB0Ve9IQpof+dD061VwsxQ59QTEEi6uQreAVaViB2Sjv2Bw7ktc6Zd6XoST6lcY4U ki0xXqiiKW6g== X-IronPort-AV: E=McAfee;i="6000,8403,9808"; a="171302350" X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="171302350" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 07:37:43 -0800 IronPort-SDR: EJanQC+tinNEqTk1/xIR0FNDd6GdqWk5lX8Bc3dx/GRmOFCIRlXZ/v0XeZbDnGCPQ1oKKtRrkw F1XD94rz3+8Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,486,1596524400"; d="scan'208";a="325628037" Received: from silpixa00399498.ir.intel.com (HELO silpixa00399498.ger.corp.intel.com) ([10.237.222.52]) by orsmga003.jf.intel.com with ESMTP; 18 Nov 2020 07:37:42 -0800 From: Anatoly Burakov To: dev@dpdk.org Cc: thomas@monjalon.net, john.mcnamara@intel.com Date: Wed, 18 Nov 2020 15:37:38 +0000 Message-Id: X-Mailer: git-send-email 2.17.1 In-Reply-To: <6d1a335178212c2983a8e59b7fcf66001c9b262a.1605713845.git.anatoly.burakov@intel.com> References: <6d1a335178212c2983a8e59b7fcf66001c9b262a.1605713845.git.anatoly.burakov@intel.com> MIME-Version: 1.0 In-Reply-To: <7d1840b4184bf363e3b9ddaff0683f13b324078a.1605031542.git.anatoly.burakov@intel.com> References: <7d1840b4184bf363e3b9ddaff0683f13b324078a.1605031542.git.anatoly.burakov@intel.com> Subject: [dpdk-dev] [PATCH v2 4/4] doc: add VFIO troubleshooting section X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" There are common problems with VFIO that get asked over and over on the mailing list. Document common problems with VFIO and how to fix them or at least figure out what went wrong. Signed-off-by: Anatoly Burakov --- doc/guides/linux_gsg/linux_drivers.rst | 43 ++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst index 741b17a644..57001c67ee 100644 --- a/doc/guides/linux_gsg/linux_drivers.rst +++ b/doc/guides/linux_gsg/linux_drivers.rst @@ -271,3 +271,46 @@ To restore device ``82:00.0`` to its original kernel binding: .. code-block:: console ./usertools/dpdk-devbind.py --bind=ixgbe 82:00.0 + +Troubleshooting VFIO +-------------------- + +In certain situations, using ``dpdk-devbind.py`` script to bing a device to VFIO +driver may fail. The first place to check is the kernel messages: + +.. code-block:: console + + # dmesg | tail + ... + [ 1297.875090] vfio-pci: probe of 0000:31:00.0 failed with error -22 + ... + +In most cases, the ``error -22`` indicates that the VFIO subsystem couldn't be +enabled because there is no IOMMU support. To check whether the kernel has been +booted with correct parameters, one can check the kernel command-line: + +.. code-block:: console + + cat /proc/cmdline + +Please refer to earlier sections on how to configure kernel parameters correctly +for your system. + +If the kernel is configured correctly, one also has to make sure that the BIOS +configuration has virtualization features (such as Intel® VT-d). There is no +standard way to check if the platform is configured correctly, so please check +with your platform documentation to see if it has such features, and how to +enable them. + +In certain distributions, default kernel configuration is such that the no-IOMMU +mode is disabled altogether at compile time. This can be checked in the boot +configuration of your system: + +.. code-block:: console + + # cat /boot/config-$(uname -r) | grep NOIOMMU + # CONFIG_VFIO_NOIOMMU is not set + +If ``CONFIG_VFIO_NOIOMMU`` is not enabled in the kernel configuration, VFIO +driver will not support the no-IOMMU mode, and other alternatives (such as UIO +drivers) will have to be used.