RE: [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl

[Tian, Kevin]

> From: Dan Williams (nvidia) <djbw@xxxxxxxxxx>
> Sent: Wednesday, May 27, 2026 2:18 PM
> 
> Alexey Kardashevskiy wrote:
> >
> >
> > On 26/5/26 01:48, Aneesh Kumar K.V (Arm) wrote:
> > > +static bool iommufd_vdevice_tsm_req_scope_valid(u32 scope)
> > > +{
> > > +	if (scope > IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_LAST)
> > > +		return false;
> > > +
> > > +	switch (scope) {
> > > +	case IOMMU_VDEVICE_TSM_REQ_PCI_INFO:
> > > +	case IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE:
> > > +	case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ:
> > > +	case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE:
> >
> > This scope thing still needs clarification.
> >
> > I have 3 types of requests to fit here, all go via VM -> KVM -> QEMU ->
> IOMMUFD -> TSM.
> >
> > 1) bind/unbind TDI <- moves to CONFIG_LOCKED, this is "OP";
> > 2) start/stop TDI <- moves to RUN, this is "GR"? Right now I route it via "OP";
> > 3) enable/disable MMIO/DMA <- no TDI state change, this is "GR" but
> which scope is it here?
> 
> The scope parameter was meant to enumerate a security model for classes
> of commands that are otherwise opaque to the kernel. However, none of
> the commands we are targeting are opaque (private specification with
> unknown effect). It now turns out there is no role for @scope for
> security.

yeah, I haven't succeeded on figuring out that role for now. It sounds an
unnecessary abstraction asking vendor specific code to translate its
command into opaque then in the end we go back to the vendor code
to decide the security scope of that opaque.

[...]
> ...or just observe that per CC arch commands are needed to setup the VM
> so per CC arch commands are needed to marshal device assignment support
> requests.
> 
> In that case pci_tsm_req_scope becomes tsm_req_type and is just:
> 
> TSM_REQ_TYPE_CCA
> TSM_REQ_TYPE_SEV
> TSM_REQ_TYPE_TDX
> 
> I am leaning towards the latter at this point.

+1