On 9/15/2026 5:25 PM, David Marchand wrote:
On Thu, 10 Sept 2026 at 14:54, Anatoly Burakov
<[email protected]> wrote:
Currently, VFIO cleanup only unregisters multiprocess callback, but does
not destroy containers, groups, and user mem maps. Do all of that on VFIO
cleanup. In order to distinguish between config that is not initialized vs.
config that has been initialized but happens to have fd == 0, move the
global VFIO enabled flag out of the config, and add a separate per-config
"enabled" flag that can be checked to avoid attempting to clean up configs
that were never initialized in the first place.
While we're at it, also harden the API against repeated initialization and
attempts at using the API without having VFIO initialized.
- At this point of the series, I don't see the need for this change.
The default config vfio_enabled should be set to 0 and could serve the
same purpose?
It is not necessary to do it in this specific patch, I just thought to
add it because having a proper rte_vfio_cleanup() implies some more
rigor than just releasing the multiprocess state. We can move it till
later, although it would require rebase work.
- Should we reset vfio_enabled in rte_vfio_cleanup()?
Yes, we should.
@@ -2218,9 +2296,72 @@ rte_vfio_container_dma_unmap(int container_fd, uint64_t
vaddr, uint64_t iova,
return container_dma_unmap(vfio_cfg, vaddr, iova, len);
}
+static void
+vfio_cleanup_config(struct vfio_config *vfio_cfg)
+{
+ unsigned int i;
+
+ for (i = 0; i < RTE_DIM(vfio_cfg->vfio_groups); i++) {
+ struct vfio_group *group = &vfio_cfg->vfio_groups[i];
+
+ if (group->group_num == -1)
+ continue;
+ if (group->devices != 0) {
+ EAL_LOG(ERR, "Cannot cleanup VFIO group %d with %d
devices",
+ group->group_num, group->devices);
+ return;
Why stop?
Should we continue for other groups?
It wouldn't really matter as cleanup would fail anyway and there's
nothing we can do about it if we couldn't close all groups. So, tomato,
tomato. We can, of course, continue here, and cleanup all groups that we
can.
--
Thanks,
Anatoly
