On Thu, Jul 16, 2026 at 05:57:49PM +0000, Michael Kelley wrote: > From: Michael Kelley <[email protected]> Sent: Sunday, June 7, 2026 7:06 PM > > > > 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 <[email protected]> > > Gentle ping: Anyone able to review this patch? There's a > Sashiko comment, but it's for an issue in an unrelated error path, > so I'm not planning to respin this patch for that comment.
Applied. Thanks.
