Re: [PATCH 08/18] PCI/TSM: Support connecting to PCIe CMA devices

[Dan Williams (nvidia)]

Alistair Francis wrote:
> On Wed, May 20, 2026 at 3:56 PM Alistair Francis <alistair23@xxxxxxxxx> wrote:
> >
> > On Fri, May 8, 2026 at 1:18 PM <alistair23@xxxxxxxxx> wrote:
> > >
> > > From: Alistair Francis <alistair.francis@xxxxxxx>
> > >
> > > In the next patch we are going to add a PCIe CMA TSM driver, as such we
> > > need to ensure that is_pci_tsm_pf0() will allow us to connect to CMA
> > > capable devices. These devices don't necessarily has DEVCAP_TEE or IDE
> > > support.
> > >
> > > As such for Root Complex Integrated Endpoint (PCI_EXP_TYPE_RC_END) we
> > > also check for the CMA DOE feature.
> >
> > @Dan Williams this is the patch I really need your thoughts on.
> >
> > The current upstream pci_tsm code only works if IDE or TDISP is
> > supported, which isn't true for CMA support.
> >
> > This patch works around that, but the more I think about it the
> > hackier it is. I have a local change that reverts this and
> > updates`tsm.c` to work with a DSM (`->dsm_dev` is NULL), but that
> > doesn't feel right either. Do you have a better idea or how to enable
> > a CMA TSM driver?
> 
> Gentle ping on this. Any thoughts here?

Apologies for not replying to this sooner.

A Device Security Manager (DSM) at a minimum provides device evidence
validation and retrieval (CMA).

So my only comments on this 08/18 patch would be why is:

	pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG, PCI_DOE_FEATURE_CMA);

...limited to root complex integrated endpoints? That capability could
appear anywhere.

No need for ->dsm_dev to be NULL, it reflects the truth that the device
being connected also hosts the DOE mailbox.

Perhaps the discomfort arises from the fact that CMA can appear on any
function while IDE and TDISP are limited to physical function0? I agree
that needs some fixups to convert the "pf0" naming to "host". Where a
pci_tsm_host is any device that knows how to speak any of CMA, IDE, or
TDISP.

In the case where a device has CMA on multiple functions, ->connect()
hould be allowed. It only comes into conflict if function0 supports
TDISP and has claimed all the sub-functions before ->connect() is
attempted on a sub-function. That seems a rare corner case.