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

On Wed, Aug 5, 2026 at 6:11=E2=80=AFPM Aneesh Kumar K.V <aneesh.kumar@kerne=
l.org> wrote:
>
> Tianyu Lan <[email protected]> writes:
>
> > On Mon, Aug 3, 2026 at 5:04=E2=80=AFPM Aneesh Kumar K.V <aneesh.kumar@k=
ernel.org> 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 =E2=80=9Cdma-m=
apping: Use
> > DMA_ATTR_CC_SHARED=E2=80=9D=EF=BC=88https://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 thi=
s
> >> 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 mino=
r
> > 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 char=
ge
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=EF=BC=88DMA_ATTR_CC_SHARED =EF=BC=89=
?
>

I think the change is simple. The issue here is how to set the attr flag fo=
r
platforms without TSM support. This patch is to make Hyper-V T-Disp case
work without changing DMA core and PCI layer.

In parallel, we may co-work to add non-TSM platform support in your DMA
CC SHARED patchset and "PCI/TSM: Core infrastructure" patchset.

--
Thanks
Tianyu Lan