Re: [PATCH v2 1/1] vfio: fix custom containers in multiprocess

[David Marchand <david.marchand@redhat.com>]

Hello Anatoly,

On Tue, 21 Oct 2025 at 15:20, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
>
> Currently, the API regarding handling custom (non-default) containers has
> a problem with how it behaves in secondary process. The expected flow for
> using custom containers is to:
>
> 1) create a new container using rte_vfio_container_create()
> 2) look up IOMMU group with rte_vfio_get_group_num()
> 3) bind group to that container using rte_vfio_group_bind()
> 4) setup device with rte_vfio_setup_device()
>
> When called from secondary process, rte_vfio_container_create() will check
> if there's space in local VFIO config, and if there is, it will call
> rte_vfio_get_container_fd() which, in secondary process, will call into a
> multiprocess code to request primary process to open container fd, and then
> pass it back to the requester. Primary process does not store this fd
> anywhere, in fact it closes it immediately after responding to the request.
>
> Following that, when we call rte_vfio_group_bind(), we check if the group
> is open locally, and if not, we will call into multiprocess code again, to
> request primary process to open the group fd for us, but since primary did
> not store any information about the new container in step 1, it will store
> the group in local config for default container, and return it to the
> secondary, who will add it to its own config for a different container.
>
> To address these issues, the following changes are made:
>
> 1) Clarify meaning of rte_vfio_get_container_fd() to only return the
>    default container, and always pick it up from process-local config
>
> 2) Avoid calling into multiprocess on rte_vfio_container_create()
>
> 3) Avoid calling into multiprocess in group-related code, except when
>    dealing with groups associated with default container
>
> As a consequence, SOCKET_REQ_DEFAULT_CONTAINER can be removed and
> consolidated with SOCKET_REQ_CONTAINER, which now only handles the
> default container.
>
> Fixes: ea2dc1066870 ("vfio: add multi container support")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>

The patch looks fine to me.

I am not clear of the implications of this change in the API and I am
a bit hesitant on marking for backport.

On the other hand, it seems this was not working in multiprocess context only.
Plus, this is about programming an iommu, and the (intended) consumers
of this API are drivers.
I found no trace of use in opensource projects using DPDK.
So the chance of breaking an application is low.

Applied, thanks.


-- 
David Marchand