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

From: Tian, Kevin

Date: Fri Nov 06 2026 - 03:07:41 EST


> From: Jacob Pan <jacob.pan@xxxxxxxxxxxxxxxxxxx>
> Sent: Friday, November 6, 2026 1:16 AM
>
> Hi Jason,
>
> On Wed, 4 Nov 2026 20:49:34 -0400
> Jason Gunthorpe <jgg@xxxxxxxx> 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;

Not sure what'd be a proper name for this, but it sounds to me that
it tries to over-abstract something into tsm. The reused logic related
to assignment or viommu is relatively small, so the other option below
sounds better if it can work.

Or it may be the original provider framework that Aneesh proposed,
so tsm/MSHV/pKVM can each register its own backend...