[PATCH 1/1] Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

[PATCH 1/1] Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

[Michael Kelley]

From: Michael Kelley <mhklinux@outlook.com>

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>
---
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

Re: [PATCH 1/1] Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] If device_register() fails in vmbus_device_register(), the error handling path panics the kernel due to a BUG_ON, and would result in a double free if the panic were bypassed.
--

commit 575a138c8a50043a8fa9993f9a0f7b0f34865b8a
Author: Michael Kelley <mhklinux@outlook.com>
Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

This commit fixes DMA allocation failures for VMBus devices in CoCo VMs.
It ensures the coherent_dma_mask is set to 64 bits at the same time the
dma_mask is configured during vmbus_device_register().

> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 23206640c6139..a6b9a33db6578 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2169,6 +2169,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

[Severity: High]
This is a pre-existing issue, but does the error handling path for
device_register() further down in this function cause a kernel panic?

If device_register() fails, the code calls put_device():

vmbus_device_register() {
    ...
    ret = device_register(&child_device_obj->device);
    if (ret) {
        pr_err("Unable to register child device\n");
        put_device(&child_device_obj->device);
        return ret;
    }
    ...
}

This triggers the release callback vmbus_device_release(), which
unconditionally invokes hv_process_channel_removal(). However,
hv_process_channel_removal() begins with:

    BUG_ON(!channel->rescind);

Since channel->rescind is false during initial channel offer processing,
would this BUG_ON fire and crash the kernel?

Additionally, if the BUG_ON were bypassed, hv_process_channel_removal()
calls free_channel(channel). The error then propagates up to
vmbus_add_channel_work(), which takes the err_deq_chan label and calls
free_channel(newchannel) again. Does this sequence result in a double free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608020616.52852-1-mhklkml@zohomail.com?part=1

RE: [PATCH 1/1] Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

[Michael Kelley]

From: Michael Kelley <mhklkml@zohomail.com> 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 <mhklinux@outlook.com>

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
> 

Re: [PATCH 1/1] Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices

[Wei Liu]

On Thu, Jul 16, 2026 at 05:57:49PM +0000, Michael Kelley wrote:
> From: Michael Kelley <mhklkml@zohomail.com> 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 <mhklinux@outlook.com>
> 
> 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.