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 DECED44099 for ; Wed, 22 May 2024 19:03:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 625244028B; Wed, 22 May 2024 19:03:45 +0200 (CEST) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by mails.dpdk.org (Postfix) with ESMTP id 10CFE400D6 for ; Wed, 22 May 2024 19:03:44 +0200 (CEST) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a5a4bc9578cso994820066b.2 for ; Wed, 22 May 2024 10:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716397423; x=1717002223; 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=pH+mRpD9J+Bi/QD/B24pfaVoNEX6sGm9D3ximW9+TRs=; b=GLO6FJ8zyNlJaGpBDRyE9uI/z5JB0Elul0U8NbzuTjgvwm1juJi1+Jn1Rq+28Huiwj Z5Aj2vCIXbHU2ln/cQM3Z/20EFz3CzuXLithv5tg1rU10lUPzeC7Mq4BBgI8wE5Gqiy2 CR+qpEOfsBfQUgtPplkvwwNZ90Q+cK8Y9NJcQOYBM/4nQLPnpbtHlMq9tooA51qoR1GO LqcYbkSUxOEezJ4j9rc4qk4k6GAJxELIu8E8s2GUirPSxD9Lixp7Y2l4ejm9zRIGXPb7 xJkjlgcrYduztCt3IchZpUXkP9yy5B7dfoPy3v9IlNi78Wmz4+RLoIFG3dU8YpYPwIZd gGpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716397423; x=1717002223; 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=pH+mRpD9J+Bi/QD/B24pfaVoNEX6sGm9D3ximW9+TRs=; b=iIaDB7yt2J/QFh0a4j3YEV5utKzHfF67Dq/B4Rz0AkpCeOdNSqYM0A+/z54ajsvj7/ rbUilUpdKPBmO9hvRdm5lymjLTBC471IK2uq1qDdvU2RR3ASfgTjQEO9IXOBSzX83hT0 Bxc4fpZLMN9U5Kfp6YO26mbGKgQ+EZYlxgNAazXklOZp/sJIOlIiUPtPU1ywdsv+uJe0 LxUF2QahYuI+3+W7N27lNJ2Aei5SIuU+Uc8fCnx7M2CiW5w7Nx/qVwI+2owwxgmFnozU 9OYASdIS7F22ad7obHm4GXyKWuhPV8/eAtGazdW2q5hOC2pAtWmL+vXhKfulqNBH8INR T/ng== X-Gm-Message-State: AOJu0Yz0GwNVEBytJITJw8lb6NbRMSBpbj9gmoXyb+nj0UOeHvtw6U+p 9vr6p6x9dnDMBaKb5XEhF/r7ORVfY/Q2yGh8qdES/r+tci/PmxDuuekJrkDxerfyjEJXvSs1kj8 /S/FmiMJ7eMFBHQgkQkL9eBQgPHpVradSC1LaUg== X-Google-Smtp-Source: AGHT+IGoAMQ2Pf65qLoF1J2vx9VSujDYuDnf0Z8yUWMOeJuHMDAE+5Uf+gRJkx5fGuX+7QGhftXHR/uIhnUkJajATvE= X-Received: by 2002:a17:906:1452:b0:a59:b02a:90da with SMTP id a640c23a62f3a-a622820ad1fmr219884166b.68.1716397423382; Wed, 22 May 2024 10:03:43 -0700 (PDT) MIME-Version: 1.0 References: <20240522102148.0db4d9b6@sovereign> In-Reply-To: From: Antonio Di Bacco Date: Wed, 22 May 2024 19:03:32 +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 I found the exact line where I get the crash (the line saying TAILQ_FOREACH= ) /* 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 tha= t > > > the secondary explicitly blocks with the --block arg ? > > > > > > IN my case this requests of mapping creates a crash in the secondary. > > > > > > Using DPDK 21.11 > > > > > > Best regards, > > > Antonio. > > > > Hi Antonio, > > > > "Secondary processes which requires access to physical devices in Prima= ry > > process, must be passed with the same allow and block options." > > > > https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html