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

[Dave Hansen <dave.hansen@intel.com>]

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?