Re: [RFC PATCH 15/15] virt: tdx-guest: Accept default DMAR entry during PCI driver attach
From: Xu Yilun
Date: Wed Oct 28 2026 - 05:45:44 EST
On Mon, Oct 26, 2026 at 03:49:30PM +0800, Xiaoyao Li wrote:
> On 9/24/2026 12:10 PM, Zhenzhong Duan wrote:
> > Before a TDI can perform DMA to guest private memory, its secure DMA
> > mapping must be accepted. This happens during driver load stage after
> > MMIO acceptance and TDI activation.
> >
> > The enable_dma callback issues TDG.DMAR.ACCEPT to set secure PASID
> > table entry to present state and target non-partitioned TD.
> >
> > The secure PASID table entry is cleared in unlock stage implicitly
> > so disable_dma is a no-op currently.
> >
> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxx>
> > ---
> > drivers/virt/coco/tdx-guest/connect.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/virt/coco/tdx-guest/connect.c b/drivers/virt/coco/tdx-guest/connect.c
> > index a9d41fd38b64..b328caac0a49 100644
> > --- a/drivers/virt/coco/tdx-guest/connect.c
> > +++ b/drivers/virt/coco/tdx-guest/connect.c
> > @@ -427,10 +427,26 @@ static int tdx_devsec_run(struct pci_dev *pdev)
> > return 0;
> > }
> >
> > +static int tdx_devsec_enable_dma(struct pci_dev *pdev)
> > +{
> > + int ret = tdx_mcall_dmar_accept(pci_dev_id(pdev), 0);
>
> after going through the series, I have a basic question on guest function_id.
>
> Per TDX connect API spec, TDG.DMAR.ACCEPT, TDG.DMAR.RELEASE,
> TDG.TDI.MMIO.ACCEPT, TDG.TDI.RD and TDG.TDI.START all require guest function_id
> as input parameter. However, the guest function_id is specified by the host VMM
> on TDH.TDI.CREATE.
>
> So how can the guest ensure pci_dev_id(pdev) is the value that will be specified
> by the host VMM?
>
> This is a strong contract, while this series doesn't mention it at all.
I think the contract is already built for legacy VM. QEMU made the
mapping between the gBDF & the device.
The TDX guest doesn't need a new contract to identify a device. Instead
the VMM tells the firmware what is the contract on TDI creation.
That's why there is a tdi_id argument on host side TSM BIND (though we
may refactor the interface later).
But yes I agree we discuss this in changelog.