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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Tianyu Lan <ltykernel@gmail.com> writes:

> On Mon, Aug 3, 2026 at 5:04 PM Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
>>
>> Tianyu Lan <ltykernel@gmail.com> 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().
>

Can we rework this patch to use that? 

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

-aneesh