[PATCH v2] eal/linux: skip vfio for non-privileged container

[Moses Young]

On 5/16/2025 2:46 PM, David Marchand wrote:
> On Thu, Mar 27, 2025 at 8:57 AM Yang Ming<ming.1.yang at nokia-sbell.com> wrote:
>> DPDK detect vfio container according the existence of vfio
>> module. But for container with non-privileged mode, there is
>> possibility that no VFIO_DIR(/dev/vfio) mapping from host to
>> container when host have both Intel NIC and Mellanox NIC but
>> this conntainer only allocate VFs from Mellanox NIC.
>> In this case, vfio kernel module has already been loaded from
>> the host.
>> This scenario will cause the error log occurs in DPDK primary
>> process as below:
>> 'EAL:   cannot open VFIO container, error 2 (No such file or
>> directory)'
>> 'EAL: VFIO support could not be initialized'
>> Because `rte_vfio_enable()` call `rte_vfio_get_container_fd()`
>> to execute `vfio_container_fd = open(VFIO_CONTAINER_PATH,
>> O_RDWR);` but VFIO_CONTAINER_PATH(/dev/vfio/vfio) doesn't exist
>> in this container.
>> This scenario will also lead to the delay of DPDK secondary
>> process because `default_vfio_cfg->vfio_enabled = 0` and
>> `default_vfio_cfg->vfio_container_fd = -1`, socket error will
>> be set in DPDK primary process when it sync this info to
>> the secondary process.
>> This patch use to skip this kind of useless detection for this
>> scenario.
>>
>> Signed-off-by: Yang Ming<ming.1.yang at nokia-sbell.com>
> With such a change, is the check on the passed kernel module still needed?

Hi David,

Thanks for your comment.

Yes. We still need this checks:
1. Module check (rte_eal_check_module(modname)) ensures the host has the 
VFIO driver loaded.
2. Directory check (opendir("/dev/vfio")) skips the open call in 
unprivileged containers without /dev/vfio, avoiding a noisy error.
This patch adds the second check. Please let me know if you'd like any 
more details!

Best regards,
Yang Ming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20250516/a0b40e03/attachment.htm>