From: Tianyu Lan <[email protected]> Sent: Tuesday, February 10, 2026 8:21 AM > > Hyper-V provides Confidential VMBus to communicate between > device model and device guest driver via encrypted/private > memory in Confidential VM. The device model is in OpenHCL > (https://openvmm.dev/guide/user_guide/openhcl.html) that > plays the paravisor rule. > > For a VMBUS device, there are two communication methods to
s/VMBUS/VMBus/ > talk with Host/Hypervisor. 1) VMBus Ring buffer 2) dynamic > DMA transition. I'm not sure what "dynamic DMA transition" is. Maybe just "DMA transfers"? Also, do the same substitution further down in this commit message. > The Confidential VMBus Ring buffer has been > upstreamed by Roman Kisel(commit 6802d8af). It's customary to use 12 character commit IDs, which would be 6802d8af47d1 in this case. > > The dynamic DMA transition of VMBus device normally goes > through DMA core and it uses SWIOTLB as bounce buffer in > CVM "CVM" is Microsoft-speak. The Linux terminology is "a CoCo VM". > to communicate with Host/Hypervisor. The Confidential > VMBus device may use private/encrypted memory to do DMA > and so the device swiotlb(bounce buffer) isn't necessary. The phrase "isn't necessary" does not capture the real issue here. Saying "isn't necessary" makes it sound like this patch is just avoids unnecessary work, so that it is a performance improvement. But that's not the case. The real issue is that swiotlb memory is decrypted. So bouncing through the swiotlb exposes to the host what is supposed to be confidential data passed on the Confidential VMBus. Disabling the swiotlb bouncing in this case is a hard requirement to preserve confidentially. So I would reword the sentences as something like this: The Confidential VMBus device can do DMA directly to private/encrypted memory. Because the swiotlb is decrypted memory, the DMA transfer must not be bounced through the swiotlb, so as to preserve confidentiality. This is different from the default for Linux CoCo VMs, so disable the VMBus device's use of swiotlb. > To disable device's swiotlb, set device->dma_io_tlb_mem > to NULL in VMBus driver and is_swiotlb_force_bounce() > always returns false. > > Suggested-by: Michael Kelley <[email protected]> > Signed-off-by: Tianyu Lan <[email protected]> > --- > Change since v1: > Use device.dma_io_tlb_mem to disable device bounce buffer > > drivers/hv/vmbus_drv.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index a53af6fe81a6..58dab8cc3fcb 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -2133,11 +2133,15 @@ int vmbus_device_register(struct hv_device > *child_device_obj) > child_device_obj->device.dma_mask = &child_device_obj->dma_mask; > dma_set_mask(&child_device_obj->device, DMA_BIT_MASK(64)); > > + device_initialize(&child_device_obj->device); > + if (child_device_obj->channel->co_external_memory) > + child_device_obj->device.dma_io_tlb_mem = NULL; > + Doing this as part of the VMBus bus driver makes sense. While directly setting device.dma_io_tlb_mem to NULL should work, it would be better to add a function to the swiotlb code to do this, and then call that function here, passing the device as an argument. The need to disable swiotlb on a device will likely arise in similar contexts (such as TDISP), and it would be better to have a swiotlb function for that purpose. This use case may be a bit ahead of the TDISP work, and having a swiotlb function in place will help ensure that duplicate mechanisms aren't created as everything comes together. See my earlier comments in [1] about the key point in the commit message, and about adding a swiotlb_dev_disable() function to the swiotlb code. Michael [1] https://lore.kernel.org/linux-hyperv/sn6pr02mb4157dae6d8cc6ba11ca87298d4...@sn6pr02mb4157.namprd02.prod.outlook.com/ > /* > * Register with the LDM. This will kick off the driver/device > * binding...which will eventually call vmbus_match() and vmbus_probe() > */ > - ret = device_register(&child_device_obj->device); > + ret = device_add(&child_device_obj->device); > if (ret) { > pr_err("Unable to register child device\n"); > put_device(&child_device_obj->device); > -- > 2.50.1
