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. Michael > --- > I have not provided a Fixes: tag because the scenario under which > the error occurs is an artificial test case that I came across > while stressing a unrelated patch set. The fix is valid for general > goodness, but the likelihood of the problem occurring in the real > world is extremely small. So I see little value in adding this > patch to the stable kernel maintainers' workload. If someone wants > to argue otherwise, I have no fundamental objection to adding the > Fixes: tag. > > drivers/hv/vmbus_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index c9eeb2ec365d..26e8273bbddd 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -2192,6 +2192,7 @@ int vmbus_device_register(struct hv_device > *child_device_obj) > child_device_obj->device.dma_parms = &child_device_obj->dma_parms; > child_device_obj->device.dma_mask = &child_device_obj->dma_mask; > dma_set_mask(&child_device_obj->device, DMA_BIT_MASK(64)); > + dma_set_coherent_mask(&child_device_obj->device, DMA_BIT_MASK(64)); > > /* > * Register with the LDM. This will kick off the driver/device > -- > 2.25.1 >
