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

[Aneesh Kumar K . V]

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.

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