[dpdk-dev] [Bug 102] IOVA mode causes deadlock

[dpdk-dev] [Bug 102] IOVA mode causes deadlock

[bugzilla]

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

            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() takes
the hotplug write lock, and continues to call rte_eal_check_dma_mask() (in case
dma_maskbits != 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 IOVA
mode.

malloc_heap.c:alloc_pages_on_heap():

        if (mcfg->dma_maskbits) {
                mask = ~((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 code
seems to think it's expecting the full mask (uint64_t).  I can't say I really
understand what's going on here, but shouldn't the allocated memory be checked
against the DMA mask? This code looks like it's checking the DMA mask against
the DMA mask.

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

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