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
