On 9/16/2026 11:42 AM, David Marchand wrote:
On Thu, 10 Sept 2026 at 14:55, Anatoly Burakov
<[email protected]> wrote:
diff --git a/lib/eal/include/dev_vfio.h b/lib/eal/include/dev_vfio.h
index f2dbf46481..c62d38e524 100644
--- a/lib/eal/include/dev_vfio.h
+++ b/lib/eal/include/dev_vfio.h
@@ -18,6 +18,7 @@
#include <stdint.h>
#include <rte_compat.h>
+#include <rte_common.h>
#ifdef __cplusplus
extern "C" {
@@ -29,8 +30,6 @@ extern "C" {
#define DEV_VFIO_CONTAINER_PATH "/dev/vfio/vfio"
#define DEV_VFIO_GROUP_FMT "/dev/vfio/%u"
#define DEV_VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
-#define DEV_VFIO_NOIOMMU_MODE \
- "/sys/module/vfio/parameters/enable_unsafe_noiommu_mode"
#endif /* RTE_EXEC_ENV_LINUX */
@@ -39,28 +38,64 @@ struct vfio_device_info;
#define DEV_VFIO_DEFAULT_CONTAINER_FD (-1)
+/**
+ * @enum dev_vfio_mode
+ * Enumeration of VFIO operational modes.
+ *
+ * These modes define how VFIO devices are accessed.
+ *
+ * - DEV_VFIO_MODE_NONE: VFIO is not enabled.
+ * - DEV_VFIO_MODE_GROUP: Legacy group mode.
+ */
+enum dev_vfio_mode {
+ DEV_VFIO_MODE_NONE = 0, /**< VFIO not enabled */
+ DEV_VFIO_MODE_GROUP, /**< Group mode */
+};
+
+/**
+ * @enum dev_vfio_iommu_mode
+ * Enumeration of VFIO IOMMU protection modes.
+ *
+ * These modes define whether devices are protected by an IOMMU.
+ *
+ * - DEV_VFIO_IOMMU_MODE_UNKNOWN: IOMMU mode has not been determined.
+ * - DEV_VFIO_IOMMU_MODE_SAFE: Devices are protected by an IOMMU.
+ * - DEV_VFIO_IOMMU_MODE_UNSAFE: Devices are not protected by an IOMMU.
+ */
+enum dev_vfio_iommu_mode {
+ DEV_VFIO_IOMMU_MODE_UNKNOWN = 0, /**< IOMMU mode not determined */
+ DEV_VFIO_IOMMU_MODE_SAFE, /**< IOMMU protection enabled */
+ DEV_VFIO_IOMMU_MODE_UNSAFE, /**< IOMMU protection disabled */
+};
My two cents.
This "safety" mode is ambiguous (for example, the bus/fslmc change
looks wrong, as I reported earlier).
Yes, that's a typo. It should've been not wrong!
The main concern for drivers is the "class" (physical, virtual) of addresses.
The noiommu notion was simple in that drivers understood they had to
handle physical addresses.
That is arguably still the case. It is the same semantic meaning, just
wrapped under a different name because I wanted to signal that using
no-iommu mode is bad practice. It's still effectively IOMMU vs no-IOMMU.
There is some other concern about iommu capability that is not
captured in the new API.
Take a look at the PCI bus for example, where some decision is taken
on a DMA mask.
Arguably this is not *VFIO* related (it's rather the property of IOMMU)
so there is little place for that notion in this API except to group all
IOMMU stuff under the same roof, which may or may not be semantically
coherent depending on your view of what this API should be.
In the end, it may mean that the whole iommu class discovery (that
impacts IOVA mode) should get revisited too... ?
At least, with an *internal* VFIO API, we can revisit more easily in
the future, so those comments are not blocking the series.
We can do all sorts of things now that we are allowed to, yes!
--
Thanks,
Anatoly
