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.ronnb...@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.