[dpdk-dev] [Bug 102] IOVA mode causes deadlock
bugzilla at dpdk.org
bugzilla at dpdk.org
Wed Oct 31 11:18:27 CET 2018
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 at dpdk.org
Reporter: mattias.ronnblom at 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.
More information about the dev
mailing list