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

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.

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.

Thanks,
Robin.

> 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