Messages in this thread |  | | From | Aneesh Kumar K.V <> | | Subject | Re: [PATCH v4 4/4] iommufd/vdevice: add TSM guest request ioctl | | Date | Tue, 28 Apr 2026 17:43:05 +0530 |
| |
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.
> > Also, since scope is now a uapi whatever in tsm is defining the values > must be moved to the uapi headers. >
Sure, I will update this in the next revision. Dan, should this be part of the TSM series?
> Probably this is not a good idea and iommufd should just have its own > enum with unique numbers for every bus and do the validation and > translation. >
-aneesh
|  |