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

Baolu Lu baolu.lu at linux.intel.com
Thu Sep 17 22:54:02 PDT 2026


On 9/16/2026 8:39 PM, Jason Gunthorpe wrote:
> On Wed, Sep 16, 2026 at 05:54:57AM +0000, Tian, Kevin wrote:
>>> At least for ARM there is effectively no entanglement with the actual
>>> host iommu driver. The viommu is entirely provided by software in the
>>> RMM world, so it can have its own dedicated driver. In ARM T=1
>>> transactions are alwayus routed to the RMM's iommu and there is no
>>> relation to the host.
>>>
>>> I am interested how Intel works here, but I thought it was similar.
>> Largely yes. Main difference at Intel side is that TDX still relies on the
>> host to initiate iotlb invalidation (upon notification from KVM on S-EPT
>> change). Currently we put this logic in intel-iommu driver but it's more
>> about wrapping invalidation info and passing it to the firmware. Moving
>> it into the tsm driver should be straightforward.
>>
>> Maybe there'll be other subtle connections to host iommu driver but
>> it doesn't sound a hard problem to solve.
> Okay, so I saw the driver posting for basic iommu support, can we try
> to rework that to be split out like Aneesh is doing so everything
> about TDX calls lives in tsm and intel iommu only provides a small API
> surface to exchange whatever details are needed to bootstrap TDX
> module?

Are you referring to this series?

https://lore.kernel.org/linux-iommu/20260915074235.1219183-1-baolu.lu@linux.intel.com/

It initializes the iommu managed by the secure world (the TDX module).

I’m happy to rework it as you suggested by moving most of the TDX-
related code into the tsm driver and leaving the host iommu driver to
provide only the necessary assistance.

Thanks,
baolu



More information about the linux-arm-kernel mailing list