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

Dave Hansen
2025-11-19T15:18:15Z

Any chance we could use english in subjects? Isn't this something more
along the lines of:

PCI: Secure Device Passthrough For TDX, initial support

I mean, "TDX Connect" is a pure marketing term that doesn't tell us
much. Right?

I'll also say that even the beginning of the cover letter doesn't help a
lot. Plain, acronym-free language when possible would be much
appreciated there and across this series.

For instance, there's not even a problem statement to be seen. I asked
ChatGPT: "write me a short, three sentence plain language paragraph
about why TDX Connect is needed on top of regular TDX"

Regular TDX keeps a guest’s memory safe but leaves the path to
physical devices exposed to the host. That means the host could
spoof a device, alter configuration, or watch DMA traffic. TDX
Connect closes that gap by letting the guest verify real devices
and encrypt the I/O link so the host can’t interfere.

That would be a great way to open a cover letter.

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:

* Ask the TDX module how much memory it wants
* Feed it with that much memory

... and voila! The fancy new extension works. Right?

But can we break this up, please?