From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D6BCD48A7E for ; Thu, 6 Nov 2025 08:28:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BAA0F40E11; Thu, 6 Nov 2025 08:28:54 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id ACA0E4013F for ; Thu, 6 Nov 2025 08:28:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762414132; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1eFpom0u6AIg3pRMSUXP6l3J1SVQQNthbms7XxtjbRs=; b=WTg1dtmHiCM3sNnuAU40P1VoQ3+vWVHrFjRvIuLoB/7m8VfyQyHTd6cvhcz/kxUCTpr3Mm w0z72Odg0htms3Dml4tXm4fEpRxIfQAmDclJSjlMuwic2+44lssI92rK7H//fo2Cejuw7k A+RY/8QgL4nB2+hesqU2mEonP9y/IJE= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-13-cACj_8EFN66m0GPwXDoCuQ-1; Thu, 06 Nov 2025 02:28:50 -0500 X-MC-Unique: cACj_8EFN66m0GPwXDoCuQ-1 X-Mimecast-MFC-AGG-ID: cACj_8EFN66m0GPwXDoCuQ_1762414129 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-594259bf71aso432104e87.3 for ; Wed, 05 Nov 2025 23:28:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762414129; x=1763018929; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1eFpom0u6AIg3pRMSUXP6l3J1SVQQNthbms7XxtjbRs=; b=Wy1QHDL0uJ6PEtef2VgxXYNSBg2I+Mj0/2YSz/A2ESnBcqPiuYJVTIiC++tvT+ggHO AhdI4XTIqU2O5oVcfEnn+26CZZydxRM3zOcaJ046Yqca9Sn6RDqEtXMcIOb9X/rWp6+d CRhJwDND6J0SA2T8S6bGkCBexQtQUsmhGRJwjPKV3MBWdm+OsawNyGQ6JtVKI4yAs1MX FjiqmuuRJl2JTvplFBX4T2vp31CkbzT9erwNmbCfASXqt/mj2nAfjvJGealekCcol5xZ FrJX93nozyc3OPQg8ltb0paB8qNpdbbZqaoxVgUWFEsopRATb8tAZ2Jn8nJLTft1CUZ3 BsWw== X-Forwarded-Encrypted: i=1; AJvYcCVXGS+XDBVlfY376NCE23squJN5u5yPbyp114+pSzdcfv1dghcf2aPblKweI+hRMfUhF5Ak20M=@dpdk.org X-Gm-Message-State: AOJu0Yw7PX9IVBYkqRxJWMmJM8oltHOklwwLR4ExmFD6l23XgMwTWmwy 5/i8AMZzaci/3CITlw50RvLoGtooJV1OUH9JhjV0wpIGwsGnuQpHHKrWrJ/JbK0X40us+M1QsZj uG6qmNr21aWbqegyO1xzpxD2o5cXtA43GR9kf1WEnowviSliMkZPtVMT7dl6dDBGcJ0oXNIrE4U +gMxsc9QvUyymPq4W7vt0LWkg= X-Gm-Gg: ASbGncsu85THemRuVZiuBcAxMvwza9ckb4O6E3aHibDJgMtxsZ/waIk9N3xiXTSyOGF MwVyRuu1JbaBrMNZEkNxniD4ywaZ4lFa4L1O9ARm5SxylVCibbfV+ueS7JTOWPZ3W/NlBKjn8pu Lo9wDk/SauyI394GiaEBCB4hIzcPLdBIKExDFv5ZfF+ueAmQzYG8AAxw1Yzw== X-Received: by 2002:a05:6512:3a86:b0:594:27c6:a03 with SMTP id 2adb3069b0e04-5943d74d4d0mr1997091e87.13.1762414129298; Wed, 05 Nov 2025 23:28:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IH9cWcFHLJQUfLE3rEx3pS9tV4SAgRWXOYhmQyOb+MjcFA+xnpQ+ekUX2e2GJ2RCDUyPGmds+PgeNeLc3CK+RM= X-Received: by 2002:a05:6512:3a86:b0:594:27c6:a03 with SMTP id 2adb3069b0e04-5943d74d4d0mr1997084e87.13.1762414128871; Wed, 05 Nov 2025 23:28:48 -0800 (PST) MIME-Version: 1.0 References: <7e195ed0245a80a7f3302ae5d3c08a66c206ca9b.1761052774.git.anatoly.burakov@intel.com> In-Reply-To: <7e195ed0245a80a7f3302ae5d3c08a66c206ca9b.1761052774.git.anatoly.burakov@intel.com> From: David Marchand Date: Thu, 6 Nov 2025 08:28:37 +0100 X-Gm-Features: AWmQ_bl9HQziBGF34tbkQGDmWpGnoQRn0aMkO4AmSals_5VPta20T_U5ZpCOyL8 Message-ID: Subject: Re: [PATCH v2 1/1] vfio: fix custom containers in multiprocess To: Anatoly Burakov Cc: dev@dpdk.org, Tyler Retzlaff , Xiao Wang , Ferruh Yigit , Junjie Chen , Maxime Coquelin , stable@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: NVay8cKJxlN9YoN4Ob6Oj0yylP3FdiqgVxKNVWiysek_1762414129 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hello Anatoly, On Tue, 21 Oct 2025 at 15:20, Anatoly Burakov 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 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