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 2EA9444099 for ; Wed, 22 May 2024 19:09:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B535C4028B; Wed, 22 May 2024 19:09:50 +0200 (CEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id 65BCD400D6 for ; Wed, 22 May 2024 19:09:49 +0200 (CEST) Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-51f72a29f13so7156937e87.3 for ; Wed, 22 May 2024 10:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716397789; x=1717002589; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3qXOPmCdFxCP2qutgtEmjRqViUWP1I4+d+TPLr5rTQE=; b=IOvUdoGSdb82eHC2ReVHfNFFM3pwelgV4u9XNaWSuYMxGCny1oucm457l0wl383XoS bmvyzNW7i2i7bvwNwmRzn1bQsArp8kqh8bZNws9FqzQn6puUCcVTSKPhcSqvuOqVDbKs 7MdPMU7NYcsj9PCXlJod9NSgEpn6yytNN2bHFaT9mYZjqgUFY2+nm/1E6i327rPx0RhX M4WphnFesV/evUePw7U/PqKACLdEORtH8ZsqVjUqdcKuBnlckfN5NP45zNPEcSgzhyoQ sidNmnYxtuNjv1OZtLtrcuwsuOMM2w2Pvp+C9onxYE0XQ2qwuSZns/FAjB+7sVNhRnhO YY/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716397789; x=1717002589; h=content-transfer-encoding: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=3qXOPmCdFxCP2qutgtEmjRqViUWP1I4+d+TPLr5rTQE=; b=ugzeAEFi72seWFYG6h8sVsy4z3Z19UXysFJa76Kess2shxjX3ygK0FKOfMMfAvmACo w+crFkLe9uXdOvzt5cz9j/QVgMeB4YN8xDaqBbsTw4UnnNDaTZUQ5Df68id9qGxiriSc /cl1zfDxIG1CyshReZta+jT28TV7WK2xFG5bmiRbKIMhlKe0NVTZLKDdWxvvxJX+58g0 pKrmfG1scN7o9TJIgxqAkRxEBmhis5DRPGAu4pJluhlTUPo2f1oAlZpuyZoBmrlfOpyp z3BMKFciUKbvHCd7k0pzFziF2uPN1BM6z1Kk2p8+l2sOgLMrNzYKi3ueGague9LrLkEC +nPA== X-Gm-Message-State: AOJu0YzscRiO1rB4SS5Av0d3ZKP9dx8mmzPU6FYhGWaNjAmEFaH+zd5Y +Zj6AX/7WYPWFcSGv9ViPX9IChwkO3sEz/vWb/qSko98SnlcuD3OENrRWFy7yhhsVyzSmxJbLWR /8ZWznBwW+4lN+ON9F++DAhUKlXE= X-Google-Smtp-Source: AGHT+IHWmO5eLEJ6jpUznLcmtHzgLxUxAzAIsL+iQ43mrSeiAssDhRr7lJOH50gicL2Yz/j+dFVskkIMVhfZRz4pU74= X-Received: by 2002:a05:6512:200c:b0:522:36f7:3660 with SMTP id 2adb3069b0e04-526bdc52301mr1669580e87.36.1716397788514; Wed, 22 May 2024 10:09:48 -0700 (PDT) MIME-Version: 1.0 References: <20240522102148.0db4d9b6@sovereign> In-Reply-To: From: Antonio Di Bacco Date: Wed, 22 May 2024 19:09:37 +0200 Message-ID: Subject: Re: Request to map PCI device in a secondary that uses the --block for that device To: Dmitry Kozlyuk Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org For completeness (vfio_res_list is NULL): (gdb) bt #0 0x00007f75f074e849 in pci_vfio_map_resource_secondary (dev=3D0x7f377c00) at ../drivers/bus/pci/linux/pci_vfio.c:901 #1 0x00007f75f074ea7f in pci_vfio_map_resource (dev=3D0x7f377c00) at ../drivers/bus/pci/linux/pci_vfio.c:958 #2 0x00007f75f0749eb5 in rte_pci_map_device (dev=3D0x7f377c00) at ../drivers/bus/pci/linux/pci.c:70 #3 0x00007f75f0747e81 in rte_pci_probe_one_driver (dr=3D0x7f75f0397100 , dev=3D0x7f377c00) at ../drivers/bus/pci/pci_common.c:251 #4 0x00007f75f074820a in pci_probe_all_drivers (dev=3D0x7f377c00) at ../drivers/bus/pci/pci_common.c:353 #5 0x00007f75f07489b8 in pci_plug (dev=3D0x7f377c10) at ../drivers/bus/pci/pci_common.c:595 #6 0x00007f75f17a0a88 in local_dev_probe (devargs=3D0x7f75e4000bac "0000:40:04.3", new_dev=3D0x7f75ea943868) at ../lib/eal/common/eal_common_dev.c:174 #7 0x00007f75f17c8832 in __handle_primary_request (param=3D0x7f75e4000b60) at ../lib/eal/common/hotplug_mp.c:242 #8 0x00007f75f17ce78d in eal_alarm_callback (arg=3D0x0) at ../lib/eal/linux/eal_alarm.c:110 #9 0x00007f75f17d38c2 in eal_intr_process_interrupts (events=3D0x7f75ea943b10, nfds=3D1) at ../lib/eal/linux/eal_interrupts.c:1025 #10 0x00007f75f17d3ba8 in eal_intr_handle_interrupts (pfd=3D16, totalfds=3D2) at ../lib/eal/linux/eal_interrupts.c:1099 #11 0x00007f75f17d3d8f in eal_intr_thread_main (arg=3D0x0) at ../lib/eal/linux/eal_interrupts.c:1171 #12 0x00007f75f17b59c6 in ctrl_thread_init (arg=3D0x7f3640d0) at ../lib/eal/common/eal_common_thread.c:206 #13 0x00007f75f1b5d802 in start_thread () from /lib64/libc.so.6 #14 0x00007f75f1afd450 in clone3 () from /lib64/libc.so.6 (gdb) p vfio_res $1 =3D (struct mapped_pci_resource *) 0x0 (gdb) p vfio_res_list $2 =3D (struct mapped_pci_res_list *) 0x0 (gdb) p pci_addr $3 =3D "0000:40:04.3", '\000' (gdb) On Wed, May 22, 2024 at 7:03=E2=80=AFPM Antonio Di Bacco wrote: > > I found the exact line where I get the crash (the line saying TAILQ_FOREA= CH) > > /* if we're in a secondary process, just find our tailq entry */ > TAILQ_FOREACH(vfio_res, vfio_res_list, next) { > if (rte_pci_addr_cmp(&vfio_res->pci_addr, > &dev->addr)) > continue; > break; > } > /* if we haven't found our tailq entry, something's wrong */ > if (vfio_res =3D=3D NULL) { > RTE_LOG(ERR, EAL, "%s cannot find TAILQ entry for PCI device!\n", > pci_addr); > return -1; > } > > On Wed, May 22, 2024 at 10:06=E2=80=AFAM Antonio Di Bacco > wrote: > > > > Thank you. > > In my case, I have the same block/allow but the primary does an > > explicit probe of a DMA engine on the processor, the secondary is > > notified and it crashes. It should not crash I suppose. > > The same software is running on several machines (100) but the problem > > is sporadic just on two of them. > > > > Very strange. > > > > Thx, > > Antonio. > > > > On Wed, May 22, 2024 at 9:21=E2=80=AFAM Dmitry Kozlyuk wrote: > > > > > > 2024-05-22 08:46 (UTC+0200), Antonio Di Bacco: > > > > Is it correct that a primary requests a secondary to map a device t= hat > > > > the secondary explicitly blocks with the --block arg ? > > > > > > > > IN my case this requests of mapping creates a crash in the secondar= y. > > > > > > > > Using DPDK 21.11 > > > > > > > > Best regards, > > > > Antonio. > > > > > > Hi Antonio, > > > > > > "Secondary processes which requires access to physical devices in Pri= mary > > > process, must be passed with the same allow and block options." > > > > > > https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html