From mboxrd@z Thu Jan  1 00:00:00 1970
From: bugzilla@dpdk.org
Subject: [Bug 102] IOVA mode causes deadlock
Date: Wed, 31 Oct 2018 10:18:27 +0000
Message-ID: <bug-102-3@http.bugs.dpdk.org/>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

https://bugs.dpdk.org/show_bug.cgi?id=3D102

            Bug ID: 102
           Summary: IOVA mode causes deadlock
           Product: DPDK
           Version: 18.11
          Hardware: x86
                OS: Linux
            Status: CONFIRMED
          Severity: normal
          Priority: Normal
         Component: core
          Assignee: dev@dpdk.org
          Reporter: mattias.ronnblom@ericsson.com
  Target Milestone: ---

As of commit fe822eb8c5651d00ef5b8eeed6f8511e7a86560f (in RC1 now), all DPDK
applications deadlocks at the time of initialization, if I have QAT SR-IOV =
VFs
bound to DPDK. VT-d and Intel IOMMU are being used. The VFs are on the host
(not in a VM).

In the first attempt to expand the heap, malloc_heap.c:try_expand_heap() ta=
kes
the hotplug write lock, and continues to call rte_eal_check_dma_mask() (in =
case
dma_maskbits !=3D 0, which with IOVA mode it is), which attempts to take the
hotplug reader lock, and deadlocks.

Beside the deadlock issue, I think there might be more issues with using IO=
VA
mode.

malloc_heap.c:alloc_pages_on_heap():

        if (mcfg->dma_maskbits) {
                mask =3D ~((1ULL << mcfg->dma_maskbits) - 1);
                printf("mask: %lu\n", mask);
                if (rte_eal_check_dma_mask(mask)) {
                        RTE_LOG(ERR, EAL,
                                "%s(): couldn't allocate memory due to DMA
mask\n",
                                __func__);
                        goto fail;
                }
        }

rte_eal_check_dma_mask() takes mask *bit count* (as a uint8_t), but this co=
de
seems to think it's expecting the full mask (uint64_t).  I can't say I real=
ly
understand what's going on here, but shouldn't the allocated memory be chec=
ked
against the DMA mask? This code looks like it's checking the DMA mask again=
st
the DMA mask.

If I back out fe822eb8c5651d00ef5b8eeed6f8511e7a86560f, I'm ending up with
non-IOVA mode, and things starts to work again.

--=20
You are receiving this mail because:
You are the assignee for the bug.=