RE: [PATCH v2 19/31] iommu/vt-d: Reserve the MSB domain ID bit for the TDX module

[Tian, Kevin]

> From: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx>
> Sent: Wednesday, April 22, 2026 2:01 PM
> 
> > Here we need more words to explain the strategy here.
> >
> > The comment says "When IOMMU is *enabled*...", but the code here
> > just checks the static capability. It's probably a design choice that you
> > don't want to add complexity on recycling DIDs when TDX connect
> > is actually enabled, but it's worth a note here.
> 
> Yes, that's the rationale. I'll add it to comments.

btw halving the DID space permanently on any platforms supporting
TDX connect doesn't sound a good design. It may break usages which
already uses more than 50% of the DID space but have no business
to do with TDX connect.

It makes more sense to cut it down in-fly when tdx connect is initialized.
If the higher half DIDs have been used then fail TDX connect. otherwise
adjust the max domain id.

> 
> >
> > btw in patch23 commit msg:
> >
> > "
> > There is no dedicated way to enumerate which IOMMU devices support
> > trusted operations. The host has to call TDH.IOMMU.SETUP on all IOMMU
> > devices and tell their trusted capability by the return value.
> > "
> >
> > which implies that ecap_tdxc() alone doesn't really report the capability?
> 
> Ah, good catch. Let me explain:
> 
> ecap_tdxc does report the capability. This bit is special cause both
> trusted part & untrusted part access it.
> 
> For IOMMU driver (which now handles the untrusted part), it can directly
> query to this bit and decide what to do.
> 
> But for tdx-host driver which handles the trusted part, it shouldn't
> speculate into the IOMMU for capability enumeration. TDX Module has more
> concerns about trusted capability, including the related I/O stack

I guess "more concerns" means that there are more conditions for
TDX module to look at beyond ecap_tdxc(), so it's not appropriate
for tdx-host driver to check ecap alone.

> capabilities e.g. SPDM/IDE cap...  So in patch23 I actually mean we
> don't have an enumeration SEAMCALL for trusted capability, I will
> refactor that message:
> 
>     There is no dedicated *SEAMCALL* to enumerate which IOMMU devices
> support
>     trusted operations...
> 
> >
> > anyway all of those need a better explanation here...