RE: [PATCH v4 4/4] iommufd/vdevice: add TSM guest request ioctl
From: Tian, Kevin
Date: Thu May 07 2026 - 23:13:06 EST
> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Tuesday, April 28, 2026 8:49 PM
>
> On Tue, Apr 28, 2026 at 05:43:05PM +0530, Aneesh Kumar K.V wrote:
> > Jason Gunthorpe <jgg@xxxxxxxx> 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.
>
Agree. another thing is, as I replied to last version, what about userspace
providing a wrong scope value then what would be the consequence...