Re: [PATCH v1 00/26] PCI/TSM: TDX Connect: SPDM Session and IDE Establishment

Dave Hansen
2025-11-19T16:19:35Z

On 11/19/25 07:50, dan.j.williams@intel.com wrote:
> "PCI/TSM: PCIe Link Encryption Establishment via TDX platform services"

That is, indeed, much better!

>> On 11/16/25 18:22, Xu Yilun wrote:
>>> arch/x86/virt/vmx/tdx/tdx.c | 740 ++++++++++++-
>>> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 32 +
>>
>> Let me know if anyone feels differently, but I really think the "TDX
>> Host Extensions" need to be reviewed as a different patch set. Sure,
>> they are a dependency for "TDX Connect". But, in the end, the host
>> extension enabling does not interact at *ALL* with the later stuff. It's
>> purely:
>
> I feel differently.
>
>> * Ask the TDX module how much memory it wants
>> * Feed it with that much memory
>>
>> ... and voila! The fancy new extension works. Right?
>
> Right, minor implementation detail of new ABIs. What does a "TDX
> Host Extensions" patch set do that does not introduce new ABI? Linux
> should not merge a patch that gives resources to the TDX Module
> independent of a intent to use the ABIs.

I was looking at the "merge" and "review" as different steps of the
process. I totally agree we shouldn't send "TDX Host Extensions" to
Linus without an in-tree user ready to use it.

But I do think there's some value in breaking this series up into pieces
that are relatively unrelated, even if there is a functional dependency
between them. My gut says that would be best done with two or more
actually separate postings. But, I'd also be quite open to reworking
this series into two distinct, logical parts.

like:

Patches 1-4: New mm support and cleanups
Patches 5-9: TDX Module Extensions, including "gifted" memory
Patches 10-12: tdx_host device support
Patches 12-99: KVM and/or PCI gunk Dave can mostly ignore :)

But the important part is considering what the logical pieces are,
breaking up the series into those chapters, and telling the story of
this series be told by putting them in order.