Re: [PATCH v2 3/3] iommufd/vdevice: add TSM guest request ioctl

[Dan Williams]

Jason Gunthorpe wrote:
> On Mon, Mar 09, 2026 at 04:47:04PM +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: scope of tsm guest request
> > + * @req_len: the blob size for @req_uptr, filled by guest
> > + * @resp_len: the blob size for @resp_uptr, filled by guest
> > + * @req_uptr: request data buffer filled by guest
> > + * @resp_uptr: response data buffer
> > + */
> 
> This needs a much better kdoc.
> 
> Refer to specs that define this.
> 
> Explain WTF scope is

I proposed @scope, yes this needs more documentation, but really it
needs more discussion first. It was inspired by 'enum fwctl_rpc_scope'

Guests that are moving the device through the TDISP setup state machine
need to ask for host services because only the host passes messages over
SPDM in all of these architectures. That is, one SPDM session per
physical device, not per assigned virtual function. In the AMD case
there is less guest direct access to the TSM so it needs to pass
additional messages that the CPU mode based TSMs do not.

Those requests are varying degrees of: host kernel cares, host kernel
does not care but can see the contents of the message, and host kernel
does not care and can not see the contents of the message beyond
envelope.

As far as the host kernel security model is concerned this becomes a
opaque implementation specific passthrough. So the role of @scope is to
have the TSM drivers declare the security model for various messages.
Put the explicit onus on the implmentations to declare that the
guest_request operation being executed in response to a KVM exit is
contained within a given security scope. See 'enum pci_tsm_req_scope'.