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 75013459AE; Mon, 16 Sep 2024 14:30:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A9784025F; Mon, 16 Sep 2024 14:30:54 +0200 (CEST) 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 7F9A340150 for ; Mon, 16 Sep 2024 14:30:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726489852; 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: content-transfer-encoding:content-transfer-encoding; bh=8DvXPn3jNbRR8RjURYq2QcTDKZBL0YyplzXURlIht80=; b=Um+OhtvPhepbLkgF2LdKuEVticsEJNQY3d+TeMqJwsgK7qj72fLENKwMUHZPmO6p/GxYwA 74hx5ocIcpnUl89gqp+ANWxBirXDMD2QX9THK905BU1UmPR4r4kyI2q1WOEwM3J/Fgb07w dfr1zclZUKqxI1P8y25IlMaZjwhXVY8= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-rpcMsNLzMHmDC_nUrE171w-1; Mon, 16 Sep 2024 08:30:50 -0400 X-MC-Unique: rpcMsNLzMHmDC_nUrE171w-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 10554195394C; Mon, 16 Sep 2024 12:30:50 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.225.123]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E41A61956086; Mon, 16 Sep 2024 12:30:48 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: Anatoly Burakov Subject: [PATCH 1/2] eal/linux: fix VFIO hotplug with multiprocess Date: Mon, 16 Sep 2024 14:30:42 +0200 Message-ID: <20240916123044.2692301-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org At the moment, if VFIO is not available at DPDK init, it won't be available unless a subsequent rte_vfio_enable() is done. Yet, even if rte_vfio_enable() is called again in primary and secondary processes, a secondary process will never get to know that VFIO has been enabled in the primary process as the MP requests handler is only registered in EAL init. On the other hand, moving the MP requests handler registration earlier in EAL init is ok, as secondary process are supposed to be waiting on eal_mcfg_wait_complete() until the primary process calls eal_mcfg_complete(). Move vfio_mp_sync_setup() in rte_vfio_enable(). Besides, rte_eal_vfio_setup() is useless and its name with a rte_ prefix is ambiguous as it gives the impression it is an exported/public symbol. Remove it and directly call rte_vfio_enable() where needed. Signed-off-by: David Marchand --- lib/eal/linux/eal.c | 18 +----------------- lib/eal/linux/eal_vfio.c | 9 ++++++--- 2 files changed, 7 insertions(+), 20 deletions(-) diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c index d742cc98e2..54577b7718 100644 --- a/lib/eal/linux/eal.c +++ b/lib/eal/linux/eal.c @@ -867,16 +867,6 @@ rte_eal_iopl_init(void) return 0; } -#ifdef VFIO_PRESENT -static int rte_eal_vfio_setup(void) -{ - if (rte_vfio_enable("vfio")) - return -1; - - return 0; -} -#endif - static void rte_eal_init_alert(const char *msg) { fprintf(stderr, "EAL: FATAL: %s\n", msg); @@ -1162,7 +1152,7 @@ rte_eal_init(int argc, char **argv) } #ifdef VFIO_PRESENT - if (rte_eal_vfio_setup() < 0) { + if (rte_vfio_enable("vfio")) { rte_eal_init_alert("Cannot init VFIO"); rte_errno = EAGAIN; rte_atomic_store_explicit(&run_once, 0, rte_memory_order_relaxed); @@ -1291,12 +1281,6 @@ rte_eal_init(int argc, char **argv) return -1; } -#ifdef VFIO_PRESENT - /* Register mp action after probe() so that we got enough info */ - if (rte_vfio_is_enabled("vfio") && vfio_mp_sync_setup() < 0) - return -1; -#endif - /* initialize default service/lcore mappings and start running. Ignore * -ENOTSUP, as it indicates no service coremask passed to EAL. */ diff --git a/lib/eal/linux/eal_vfio.c b/lib/eal/linux/eal_vfio.c index 4e69e72e3b..7132e24cba 100644 --- a/lib/eal/linux/eal_vfio.c +++ b/lib/eal/linux/eal_vfio.c @@ -1120,9 +1120,12 @@ rte_vfio_enable(const char *modname) } if (internal_conf->process_type == RTE_PROC_PRIMARY) { - /* open a new container */ - default_vfio_cfg->vfio_container_fd = - rte_vfio_get_container_fd(); + if (vfio_mp_sync_setup() == -1) { + default_vfio_cfg->vfio_container_fd = -1; + } else { + /* open a new container */ + default_vfio_cfg->vfio_container_fd = rte_vfio_get_container_fd(); + } } else { /* get the default container from the primary process */ default_vfio_cfg->vfio_container_fd = -- 2.46.0