On Thu, Feb 12, 2026 at 2:00 AM Michael Kelley <[email protected]> wrote:
>
> 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
Hi Michael:
Thanks for your review. Will add swiotlb_dev_disable() in the next version.
>
> [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
--
Thanks
Tianyu Lan
