Re: [RFC PATCH 1/1] x86/VMBus: DMA transfer with encrypted memory in Coco VM

On Thu, Aug 6, 2026 at 11:14 PM Robin Murphy <[email protected]> wrote:
>
> On 2026-08-06 3:21 pm, Tianyu Lan wrote:
> > On Wed, Aug 5, 2026 at 6:11 PM Aneesh Kumar K.V <[email protected]> wrote:
> >>
> >> Tianyu Lan <[email protected]> writes:
> >>
> >>> On Mon, Aug 3, 2026 at 5:04 PM Aneesh Kumar K.V <[email protected]> wrote:
> >>>>
> >>>> Tianyu Lan <[email protected]> writes:
> >>>>
> >>>>> In CoCo VMs, system memory is encrypted by default.
> >>>>> Device drivers typically rely on the DMA core's
> >>>>> SWIOTLB as a bounce buffer for DMA operations, providing
> >>>>> decrypted memory that can be shared between the guest and
> >>>>> host.
> >>>>>
> >>>>> For PCI devices with T-Disp support and Confidential
> >>>>> VMBus devices (https://lkml.org/lkml/2026/7/27/1733) can
> >>>>> perform DMA transfers directly with private/encrypted
> >>>>> memory in a CoCo VM.
> >>>>>
> >>>>> To support DMA transfer with encrypted memory, Hyper-V
> >>>>> DMA ops are introduced and bypass some API which may
> >>>>> use swiotlb as bounce buffer.
> >>>>>
> >>>>> The DMA ops used is global data structure(see get_arch_
> >>>>> dma_ops() and get_dma_ops() for details). There is no
> >>>>> need to set up for each device individually.
> >>>>>
> >>>>
> >>>> Can we use __DMA_ATTR_ALLOC_CC_SHARED instead of checking
> >>>> hyperv_private_memory_dma(dev) directly? Also, would it be possible to
> >>>> encapsulate this logic in something like force_dma_encrypted(dev)?
> >>>>
> >>>
> >>> Hi Aneesh:
> >>>        Thanks for your review. I go through your patchset “dma-mapping: Use
> >>> DMA_ATTR_CC_SHARED”（https://lkml.org/lkml/2026/6/4/588). This patch
> >>> is compatible with your DMA_ATTR_CC_SHARED attr work in dma-mapping
> >>> layer. Once dma ops callbacks get DMA_ATTR_CC_SHARED attr flag and
> >>> it may use the flag to replace hyperv_private_memory_dma().
> >>>
> >>>
> >>>> Looking at functions such as hyperv_dma_alloc_coherent(), how does this
> >>>> differ from dma_direct_alloc()?
> >>>>
> >>> hyperv_dma_alloc_coherent() is to allocate memory and returns encrypted
> >>> memory address directly when hyperv_private_memory_dma() is ture.
> >>> This change is to keep all changes under Hyper-V subsystem and it's
> >>> also compatible with existing solution which changes DMA core with minor
> >>> changes.
> >>
> >>
> >> If we update force_dma_unencrypted(dev) to return false when an
> >> encrypted memory address is required, wouldn't the existing DMA-direct
> >> support handle this case? Or are there issues with the existing code? If
> >> so, could you explain them in more detail?
> >>
> >
> > Hyper-V Coco VM with T-disp scenario is to run a paravior(lightweight L1
> > hypervisor) with normal guest (Detail please see 13.2. OpenHCL Architecture
> > https://openvmmdev/guide/user_guide/openhcl.html). The paravisor is in charge
> > of talking with hardware to accept PCI devices for Normal guest.
> >
> > When PCI device is assigned to normal guest, __device_cc_accepted() should
> > always return true for this device.  Then, DMA core will not use
> > bounce buffer and
> > unencrypted memory address for the device.
> >
> > However, __device_cc_accepted() is based on TSM framework and Hyper-V
> > doesn't support it. This means normal guest will not use TSM guest driver
> > and so current code doesn't work. It's necessary to introduce an API for
> > platforms without TSM support to mask the PCI device to be "accepted".
> >
> >>
> >> Can we rework this patch to use that（DMA_ATTR_CC_SHARED ）?
> >>
> >
> > I think the change is simple. The issue here is how to set the attr flag for
> > platforms without TSM support. This patch is to make Hyper-V T-Disp case
> > work without changing DMA core and PCI layer.
>
> I don't see why Hyper-V would need to change any other layer. We're
> proposing a generic notion of device_cc_accepted() which requires the
> bus code to decide what it means to "accept" a device - TSM will be
> PCI's standard way to do that; meanwhile VMbus should be free to call
> device_cc_accept() for whatever VMbus devices it fancies. That would be
> this patch done already.
>

Hi Robin:
      Thanks for your review. For Confidential VMBus device, we may call
device_cc_accept() in VMBus driver code directly to mark the device "accepted"
when it's enumerated..

> And similarly if you also want to auto-accept PCI devices via some
> Hyper-V-specific non-TDISP mechanism, I'd expect there to be some way of
> doing that from the pci-hyperv driver without needing to hack or
> reimplement common code.
>

For PCI devices with T-Disp, Hyper-V case will be different and the T-Disp
code(e.g, TSM) will be in the paravior. So it will not run TSM code in
the normal
guest. I think it may work via registering a PCI bus notification
event in Hyper-V
PCI driver and mark the device to be "accepted" when get a new device event.
I will have a try.

These changes will depend on "DMA CC SHARED" and "PCI/TSM: Core
infrastructure" patchset. device_cc_accept() seems to be reworked in the
latest TSM patch.

Hyper-V dma ops patch is to keep all changes in Hyper-V subsystem and
may combine with "PCI/TSM: Core infrastructure" and "PCI/TSM: Core
infrastructure" according to the upstream process. The dma ops call also may
device->p->tcb/accept field to choose bounce buffer or encrypt memory.
--
Thanks
Tianyu Lan