From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: david.marchand@redhat.com, jerinj@marvell.com, thomas@monjalon.net
Subject: [dpdk-dev] [PATCH] eal: pick IOVA as PA if IOMMU is not available
Date: Wed, 24 Jul 2019 17:46:35 +0100 [thread overview]
Message-ID: <5d8f83fb7dd574d83a044c6a01e2613798f256c3.1563986790.git.anatoly.burakov@intel.com> (raw)
When IOMMU is not available, /sys/kernel/iommu_groups will not be
populated. This is happening since at least 3.6 when VFIO support
was added. If the directory is empty, EAL should not pick IOVA as
VA as the default IOVA mode.
We also assume that VFIO equals IOMMU, so if VFIO support is not
compiled, we always assume IOMMU support is not available.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/linux/eal/eal.c | 11 ++++++--
lib/librte_eal/linux/eal/eal_vfio.c | 39 +++++++++++++++++++++++++++++
lib/librte_eal/linux/eal/eal_vfio.h | 2 ++
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 34db78753..584f97a96 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -1061,8 +1061,15 @@ rte_eal_init(int argc, char **argv)
enum rte_iova_mode iova_mode = rte_bus_get_iommu_class();
if (iova_mode == RTE_IOVA_DC) {
- iova_mode = RTE_IOVA_VA;
- RTE_LOG(DEBUG, EAL, "Buses did not request a specific IOVA mode, select IOVA as VA mode.\n");
+ /* if we have an IOMMU, pick IOVA as VA mode */
+ if (vfio_iommu_enabled()) {
+ iova_mode = RTE_IOVA_VA;
+ RTE_LOG(DEBUG, EAL, "Buses did not request a specific IOVA mode, selecting IOVA as VA mode.\n");
+ } else {
+ iova_mode = RTE_IOVA_PA;
+ RTE_LOG(DEBUG, EAL, "Buses did not request a specific IOVA mode, but IOMMU is not available.\n");
+ RTE_LOG(DEBUG, EAL, "Selecting IOVA as PA mode.\n");
+ }
}
#ifdef RTE_LIBRTE_KNI
/* Workaround for KNI which requires physical address to work */
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index 501c74f23..6d5ca7903 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -2,6 +2,7 @@
* Copyright(c) 2010-2018 Intel Corporation
*/
+#include <dirent.h>
#include <inttypes.h>
#include <string.h>
#include <fcntl.h>
@@ -23,6 +24,8 @@
#define VFIO_MEM_EVENT_CLB_NAME "vfio_mem_event_clb"
+#define VFIO_KERNEL_IOMMU_GROUPS_PATH "/sys/kernel/iommu_groups"
+
/* hot plug/unplug of VFIO groups may cause all DMA maps to be dropped. we can
* recreate the mappings for DPDK segments, but we cannot do so for memory that
* was registered by the user themselves, so we need to store the user mappings
@@ -2026,6 +2029,33 @@ rte_vfio_container_dma_unmap(int container_fd, uint64_t vaddr, uint64_t iova,
return container_dma_unmap(vfio_cfg, vaddr, iova, len);
}
+/*
+ * on Linux 3.6+, even if VFIO is not loaded, whenever IOMMU is enabled in the
+ * BIOS and in the kernel, /sys/kernel/iommu_groups path will contain kernel
+ * IOMMU groups. If IOMMU is not enabled, that path would be empty. Therefore,
+ * checking if the path is empty will tell us if IOMMU is enabled.
+ */
+int
+vfio_iommu_enabled(void)
+{
+ DIR *dir = opendir(VFIO_KERNEL_IOMMU_GROUPS_PATH);
+ struct dirent *d;
+ int n = 0;
+
+ /* if directory doesn't exist, assume IOMMU is not enabled */
+ if (dir == NULL)
+ return 0;
+
+ while ((d = readdir(dir)) != NULL) {
+ /* skip dot and dot-dot */
+ if (++n > 2)
+ break;
+ }
+ closedir(dir);
+
+ return n > 2;
+}
+
#else
int
@@ -2146,4 +2176,13 @@ rte_vfio_container_dma_unmap(__rte_unused int container_fd,
return -1;
}
+/*
+ * VFIO not compiled, so IOMMU unsupported.
+ */
+int
+vfio_iommu_enabled(void)
+{
+ return 0;
+}
+
#endif /* VFIO_PRESENT */
diff --git a/lib/librte_eal/linux/eal/eal_vfio.h b/lib/librte_eal/linux/eal/eal_vfio.h
index cb2d35fb1..58c7a7309 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.h
+++ b/lib/librte_eal/linux/eal/eal_vfio.h
@@ -133,6 +133,8 @@ vfio_has_supported_extensions(int vfio_container_fd);
int vfio_mp_sync_setup(void);
+int vfio_iommu_enabled(void);
+
#define EAL_VFIO_MP "eal_vfio_mp_sync"
#define SOCKET_REQ_CONTAINER 0x100
--
2.17.1
next reply other threads:[~2019-07-24 16:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 16:46 Anatoly Burakov [this message]
2019-07-25 8:05 ` David Marchand
2019-07-25 9:31 ` Burakov, Anatoly
2019-07-25 9:35 ` David Marchand
2019-07-25 9:38 ` Burakov, Anatoly
2019-07-25 9:40 ` Burakov, Anatoly
2019-07-25 18:58 ` Thomas Monjalon
2019-07-25 9:52 ` [dpdk-dev] [PATCH v2] " Anatoly Burakov
2019-07-25 9:56 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-25 11:05 ` [dpdk-dev] [PATCH v3] " Anatoly Burakov
2019-07-26 5:08 ` Stojaczyk, Dariusz
2019-07-26 15:37 ` [dpdk-dev] [PATCH v4] " Anatoly Burakov
2019-07-29 9:31 ` David Marchand
2019-07-29 11:18 ` Burakov, Anatoly
2019-07-29 13:52 ` [dpdk-dev] [PATCH v5] " Anatoly Burakov
2019-07-30 7:21 ` David Marchand
2019-07-30 8:10 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d8f83fb7dd574d83a044c6a01e2613798f256c3.1563986790.git.anatoly.burakov@intel.com \
--to=anatoly.burakov@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).