Re: [PATCH v4 4/4] iommufd/vdevice: add TSM guest request ioctl

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Apr 28, 2026 at 05:43:05PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
> 
> > On Mon, Apr 27, 2026 at 11:40:05AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> +/**
> >> + * struct iommu_vdevice_tsm_guest_request - ioctl(IOMMU_VDEVICE_TSM_GUEST_REQUEST)
> >> + * @size: sizeof(struct iommu_vdevice_tsm_guest_request)
> >> + * @vdevice_id: vDevice ID the guest request is for
> >> + * @scope: Bus-specific scope classification for the guest request
> >> + * @req_len: Size in bytes of the input payload at @req_uptr
> >> + * @resp_len: Size in bytes of the output buffer at @resp_uptr
> >> + * @__reserved: Must be 0
> >> + * @req_uptr: Userspace pointer to the guest-provided request payload
> >> + * @resp_uptr: Userspace pointer to the guest response buffer
> >> + *
> >> + * Forward a guest 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 meaning and valid values of @scope are defined by the TSM backend for
> >> + * the device bus type.
> >
> > If you want to do this then you have to also provide a way to discover
> > what the TSM backend is so userspace can form the correct numbers.
> >
> 
> These guest-driven requests end up in the correct VMM backend, which
> should already be aware of the scope value to use. In the case of ARM
> CCA, the RHI calls include a device ID (vdev_id), which the VMM can use
> to determine the appropriate scope value.

That seems kind of indirect, we technically support multiple TSMs in
the kernel, how does it all get reconciled?

Passing overlapping numbers here without any way to tell them apart is
not a good uapi design.

Jason