diff options
| author | Michael Kelley <mhklinux@outlook.com> | 2026-06-07 19:06:16 -0700 |
|---|---|---|
| committer | Wei Liu <wei.liu@kernel.org> | 2026-07-22 23:50:26 +0000 |
| commit | ab96bc97cdcf77c6f38634c73d00074c4f92c324 (patch) | |
| tree | 24aaa0605ffd8f0573d98fd22c5758f4f977241d /tools/perf/scripts/python/flamegraph.py | |
| parent | d6f0248f04a96249660591e47fcf37ba98ac7ea3 (diff) | |
Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices
In current code, the coherent_dma_mask for VMBus devices is not set, so
it has the default value of 0, which essentially means "invalid". Because
drivers for VMBus devices do not use dma_alloc_*() functions, the usual
use of the coherent mask does not occur, and no errors result.
However, a valid coherent_dma_mask may be needed even though the drivers
don't use dma_alloc_*() functions. In a CoCo VM, the VMBus storvsc and
netvsc drivers must bounce buffer DMA operations through the swiotlb
because the Hyper-V host can't DMA into encrypted guest memory. If the
kernel is built with CONFIG_SWIOTLB_DYNAMIC and the initial swiotlb size
is small, swiotlb code may need to grow the swiotlb in response to a DMA
mapping request. That growth first allocates a transient pool while the
swiotlb is expanded in the background. The transient pool memory is
allocated from the DMA atomic pools, and the allocation code checks for
a valid coherent_dma_mask. With current code, this check fails, then the
DMA mapping request from the storvsc or netvsc driver fails, and finally
an I/O error occurs.
Fix this problem by setting coherent_dma_mask for VMBus devices at the
same time that dma_mask is set. Being a synthetic bus, VMBus does not
have any restrictions on coherent DMA, so the coherent mask is set to
the full 64 bits for all VMBus devices, just like with dma_mask.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/flamegraph.py')
0 files changed, 0 insertions, 0 deletions
