RE: [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Wednesday, September 9, 2026 8:46 PM
> 
> On Wed, Sep 09, 2026 at 03:39:31PM +0530, Aneesh Kumar K.V wrote:
[...]
> > The TSM disconnect path will now fail while any vdevice is alive or
> > active.
> 
> Yes, that's makes sense.
> 
> > Destroying a vdevice will unlock and destroy the VDEV.
> 
> Yes
> 
> > I think we can also unmap its MMIO mappings at that point, provided
> > we track the mapping requests in a list alongside the vdevice
> > details.
> 
> The mmio is owned by vfio, there should be a handshake in VFIO to
> remove mmio when it becomes private, otherwise I don't think we need
> to do anything more?

for TDX a callback in VFIO is invoked to revoke the dmabuf.

btw I didn't see any dmabuf related in this series (even in a hackish
way as Yilun sent out last year). Is it not required by CCA or just
skipped now waiting for the framework to be settled?

> 
> > All CCA operations will use pci_tsm_pf0::lock, though I think the
> > locking can be made more fine-grained.
> 
> Sure
> 
> > I will send a cleaned-up series so that we can review the code changes.
> 
> Does it seems reasonable to you? Was there any oddness with modeling
> the vdev/bind through the viommu?
> 

Try to catch up the implied changes to other arch's...

So viommu will become the abstraction point for tsm operations and
directly talks to the tsm driver instead of going through the merged 
tsm_ops (bind/unbind/guest_req).

currently what tsm_ops provides additionally is more about synchronization
with connect/disconnect, otherwise just calls into underlying tsm driver. As
long as viommu creation holds a reference to tsm then disconnection is
blocked then it's safe.

Is that the rationale behind?

and IOMMU_VDEVICE_TSM_BIND will be removed. Seems originally this series
does SMC_RMI_VDEV_CREATE and SMC_RMI_VDEV_LOCK both in tsm
bind op. Then the proposal is moving them all to vdevice creation time so
no separate bind step is required.

Does it mean that ARM CCA is essentially an early-bind model i.e. the TDI
starts in locked state from guest p.o.v.?

but https://lore.kernel.org/all/yq5aecfbzjyk.fsf@xxxxxxxxxx/ seems to indicate
that guest_req() still handles the bind request from the guest:

"
- cca_tsm_guest_req() now handles TSM_REQ_SET_TDI_STATE requests for
   the unlocked, locked, and running states.
"

a bit confusing, but maybe due to stale info cited from different timing...

for TDX we're currently pursuing a late-bind model (i.e. TDI starts in shared
state in guest), so a separate bind interface is still necessary. We could look
at whether it should be an explicit @bind viommu op or carried by 
@guest_req (say, if most preparation works can be moved to vdevice creation).

any other suggested changes to think about?

btw per past discussions VFIO should block some operations (reset, etc.)
while a TDI is locked. Do we expect a callback into VFIO to notify the locked
state, or require VFIO's own interface to place a cdev into a special state
which prevents sensitive operations even before binding it to iommufd
(and allow creating TDI vdevice only on such idevice)?

Thanks
Kevin