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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:

> "Dan Williams (nvidia)" <djbw@kernel.org> writes:
>
>> Alexey Kardashevskiy wrote:
>>>

......

>>> 
>>> I have 3 types of requests to fit here, all go via VM -> KVM -> QEMU -> IOMMUFD -> TSM.
>>> 
>>> 1) bind/unbind TDI <- moves to CONFIG_LOCKED, this is "OP";
>>> 2) start/stop TDI <- moves to RUN, this is "GR"? Right now I route it via "OP";
>>> 3) enable/disable MMIO/DMA <- no TDI state change, this is "GR" but which scope is it here?
>>
>> The scope parameter was meant to enumerate a security model for classes
>> of commands that are otherwise opaque to the kernel. However, none of
>> the commands we are targeting are opaque (private specification with
>> unknown effect). It now turns out there is no role for @scope for
>> security.
>>
>> Now a command family that iommufd can validate seems useful. As it
>> stands this implementation aliases command codes across TSMs. Do we
>> proceed with creating an actual shared command uapi for the truly shared
>> commands:
>>
>> TSM_REQ_TYPE_DEFAULT: Commands every arch needs
>> TSM_REQ_READ_OBJECT
>> TSM_REQ_REGEN_OBJECT
>> TSM_REQ_OBJECT_INFO
>> TSM_REQ_VALIDATE_MMIO
>> TSM_REQ_SET_TDI_STATE
>>
>> TSM_REQ_TYPE_SEV: Commands only SEV needs
>> TSM_REQ_SEV_ENABLE_DMA
>> TSM_REQ_SEV_DISABLE_DMA
>>
>> ...or just observe that per CC arch commands are needed to setup the VM
>> so per CC arch commands are needed to marshal device assignment support
>> requests.
>>
>> 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.
>
> 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 ?.

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;


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. 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?

-aneesh