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). 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. 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. 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. -- David Marchand
