Re: [PATCH v8 12/15] iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations

[Jacob Pan <jacob.pan@linux.microsoft.com>]

Hi Jason,

On Wed, 4 Nov 2026 20:49:34 -0400
Jason Gunthorpe <jgg@ziepe.ca> wrote:

> On Wed, Nov 04, 2026 at 03:23:51PM -0800, Jacob Pan wrote:
> 
> > I am thinking MSHV/pKVM can register an assignment-only tsm_dev to
> > leverage this? Could PCI/TSM support this role without
> > device-security?  
> 
> It is certainly not what TSM was originally imagined for, but with our
> new arrangement, yah maybe so?
I will rebase on this set and send out patches for a detailed review.

> TSM basically just becomes this weird overlay driver on the PCI device
> that does stuff. Some of the stuff it might do:
>  - Register an attestation subsystem device to do SPDM
>  - Register to allow iommufd to create a viommu
>  - Some status sysfs ?
>  - ??
> 
So we may expand pci tsm to have more than one role? currently it has
one.
int pci_tsm_register(struct tsm_dev *tsm_dev) {
...
	roles = is_link_tsm(tsm_dev) + is_devsec_tsm(tsm_dev) +
		is_assignment_tsm(tsm_dev);
	if (roles != 1)
		return -EINVAL;
> It all seems separable and composable to me, so if you don't want to
> launch an attestation subsystem device because there is no SPDM then I
> think that might be OK?
> 
> Another option would be to somehow obtain the viommu from the kvm file
> descriptor and rely on the fd to handle the module pinning/etc. I
> don't know how to do that nicely with the way the modules work
> though..
I did this in mshv-iommufd RFC to associate hypervisor FD file to
viommu.
VMM:
	struct iommu_viommu_hypervisor hypervisor = {
		.vm_fd = vm_fd,
	};
	struct iommu_viommu_alloc alloc = {
		.size = sizeof(alloc),
		.type = IOMMU_VIOMMU_TYPE_HYPERVISOR,
		.dev_id = dev_id,
		.data_len = sizeof(hypervisor),
		.data_uptr = (uintptr_t)&hypervisor,
	};
	rc = do_ioctl(iommufd, IOMMU_VIOMMU_ALLOC, &alloc,
		      "IOMMU_VIOMMU_ALLOC");

Since mshv creates partition file with anon_inode_getfile() which does a
try_module_get(fops->owner), then in mshv_viommu_init, it does
fget(hypervisor.vm_fd) which will indirectly keep the module pinned.

I guess we have to enforce this pattern to make it universally viable?

Thanks,

Jacob