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

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

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@ziepe.ca>
> 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@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.
> 

Agree. another thing is, as I replied to last version, what about userspace
providing a wrong scope value then what would be the consequence...

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

[Aneesh Kumar K.V]

"Tian, Kevin" <kevin.tian@intel.com> writes:

>> From: Jason Gunthorpe <jgg@ziepe.ca>
>> 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@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.
>> 
>
> Agree. another thing is, as I replied to last version, what about userspace
> providing a wrong scope value then what would be the consequence...


I will wait for Dan’s feedback on how we should handle the scope. We may
have to move that to the generic headers as part of the TSM patchset.

Regarding what happens when an invalid scope is passed: tsm_guest_req()
currently only handles pci_device, and the backend driver’s
pci_tsm_guest_req() callback will reject unsupported scope values.

I understand that we may want to add some checks in the generic ioctl
handler once these scope values are moved out of PCI TSM.

-aneesh