Re: [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl

["Dan Williams (nvidia)" <djbw@kernel.org>]

Aneesh Kumar K.V wrote:
> >> I am leaning towards the latter at this point.
> >
> > But we already have struct pci_tsm_ops::guest_req, which is specific to
> > the underlying CC architecture. From the above, pci_tsm_req_scope also
> > appears to carry the same information. Is that useful?
> >
> 
> I think there is value in having the VMM express the guest’s
> confidential computing architecture, so that the TSM backend can
> validate whether it should handle that guest request ?.

Yes, that is the idea.

> So it would not be the IOMMU validating the scope value, but rather
> pci_tsm_ops::guest_req.
> 
> static ssize_t cca_tsm_guest_req(struct pci_tdi *tdi, enum pci_tsm_req_scope scope,
> 		sockptr_t req, size_t req_len, sockptr_t resp,
> 		size_t resp_len, u64 *tsm_code)
> {
> 	struct pci_dev *pdev = tdi->pdev;
> 
> 	/* reject the guest request if VMM was using the link tsm wrongly. The guest
> 	 * was using a wrong CC archiecture with this link tsm
> 	 */
> 	if (scope != TSM_REQ_TYPE_CCA)
> 		return -EINVAL;

Right, iommufd is tunneling TSM requests. The tunnel should have an
envelope of TSM_REQ_TYPE_* and an @op field. The TSM driver gets those
from iommufd, validates the envelope and then processes @req.

This self-consistency and explicitness also buys some future-proofing.
It allows for alternate command sets within an arch, cross TSM
implementation shared commands, IOMMUFD-to-TSM requests outside of guest
requests.

> Jason Gunthorpe <jgg@ziepe.ca> writes:
> 
> > On Tue, May 26, 2026 at 11:17:50PM -0700, Dan Williams (nvidia) wrote:
> >
> >> In that case pci_tsm_req_scope becomes tsm_req_type and is just:
> >> 
> >> TSM_REQ_TYPE_CCA
> >> TSM_REQ_TYPE_SEV
> >> TSM_REQ_TYPE_TDX
> >> 
> >> I am leaning towards the latter at this point.
> >
> > Yeah, this sounds good. I would also include an common op field that
> > can be decoded by the TSM driver based on the TYPE above, and the
> > usual in/out message buffers.
> 
> We already have iommufd_vdevice_tsm_op_ioctl() to handle common
> operations.

Per above, I believe this is about an @op value in a common location
that iommufd can forward to the backend for validation of guest
requests.

> Right now, it handles IOMMU_VDEVICE_TSM_BIND and
> IOMMU_VDEVICE_TSM_UNBIND. I guess we should move TSM_REQ_SET_TDI_STATE
> operations to that as well?

I think we can wait to move it to its own IOMMU operation unless/until
there is a need to set RUN outside of an explicit guest request, right?