Re: [RFC PATCH 15/15] virt: tdx-guest: Accept default DMAR entry during PCI driver attach

[Xu Yilun <yilun.xu@linux.intel.com>]

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@intel.com>
> > ---
> >  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.