Re: [RFC PATCH v6 09/11] iommufd: Add the vdevice TSM request ioctl

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Sep 30, 2026 at 01:33:17PM +0530, Aneesh Kumar K.V wrote:
> > Why would it ever not be tied to userspace pointers? I don't want
> > an in kernel user ever using this kind of struct?
> 
> The previous discussion suggested that another kernel subsystem might
> need to use this low-level TSM interface, although no concrete example
> was identified. In other words, an opaque guest request could be issued
> from either userspace or kernel space. 

Don't do it without a user then.

Directly coupling KVM to iommufd is some other future topic. I don't
think KVM should be coupled to TSM.

> > That seems wrong.. The hypervisor should not have control over T=1
> > DMA.
>
> This was added specifically for AMD SEV, which requires an IOMMU-side
> update to enable DMA.

See my remarks to Vasant. I want to take a very careful look at this
list eventually, but for now lets focus on the other parts and keep
this seperate.

> We have gone through several iterations to identify the guest
> passthrough request facility we need. IIUC, both TDX and CCA give the
> hypervisor some control over the request type, while SEV-TIO is more
> opaque.

Is there a record? I would be interested to read a summary

Maybe you can summarize the details in the comments. Eg define exactly
what spec operation each arch will implement under every proposed
call?

> >> +/**
> >> + * struct iommu_vdevice_tsm_req - ioctl(IOMMU_VDEVICE_TSM_REQ)
> >> + * @size: sizeof(struct iommu_vdevice_tsm_req)
> >> + * @vdevice_id: vDevice ID the guest request is for
> >> + * @op: One of enum iommu_vdevice_tsm_guest_req_op
> >> + * @tvm_arch: One of enum iommu_vdevice_tsm_guest_tvm_arch
> >> + * @req_len: Size in bytes of the input payload at @req_uptr
> >> + * @resp_len: Size in bytes of the output buffer at @resp_uptr
> >> + * @req_uptr: Userspace pointer to the guest-provided request payload
> >> + * @resp_uptr: Userspace pointer to the guest response buffer
> >> + * @tsm_code: TSM-specific result code returned by the TSM implementation
> >> + *
> >> + * Forward a TSM request to the TSM bound vDevice. This is intended for
> >> + * guest TSM/TDISP message transport where the host kernel only marshals
> >> + * bytes between userspace and the TSM implementation.
> >> + *
> >> + * The request operation is guest initiated. The TSM backend validates
> >> + * @tvm_arch against its bound TVM architecture assumptions.
> >> + *
> >> + * The request payload is read from @req_uptr/@req_len. If a response is
> >> + * expected, userspace provides @resp_uptr/@resp_len as writable storage for
> >> + * response bytes returned by the TSM path.
> >> + *
> >> + * The ioctl is only suitable for commands and results that the host kernel
> >> + * has no use, the host is only facilitating guest to TSM communication.
> >> + */
> >> +struct iommu_vdevice_tsm_req {
> >> +	__u32 size;
> >> +	__u32 vdevice_id;
> >> +	__u32 op;
> >> +	__u32 tvm_arch;
> >> +	__u32 req_len;
> >> +	__u32 resp_len;
> >> +	__aligned_u64 req_uptr;
> >> +	__aligned_u64 resp_uptr;
> >> +	__aligned_u64 tsm_code;
> >
> > out_tsm_code
> >
> 
> That is required for SEV-TIO.

I mean spell it 'out_tsm_code' since it is written as an output, that
is the convention in iommufd structs

Separately I also don't know why we'd need it since we have an entire
resp_uptr. If the arch specific action needs an arch specific code, it
can go in the arch specific resp struct.

Jason