Re: [RFC PATCH 09/15] virt: tdx-guest: Capture the TDI report during device lock

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Mon, 2026-11-02 at 20:36 -0400, Jason Gunthorpe wrote:
> > You don't want the reviewer to have to piece together a puzzle by holding a
> > bunch of unresolved things in their head as they read the whole thing. Seems
> > like a valid comment to me. But the solution is not always just to add more
> > things to the log.
> > 
> > But I think we are still going to break this series apart into subsections
> > for getting x86 acks. Consider what could covered in a subsection
> > coverletter too, for designing something with overall reviewability.
> 
> I would prefer the arch code only contain enough to do the very low
> level interface with the TDX module.

In the past TDX work, we have been making it so the TDX module call wrappers
were designed based on what the callers needed. So you don't end up with
something on the other side just wrapping the wrapper with what is really
needed. Similarly, on the arch x86 side there is a desire to not hand raw u64's,
etc and instead of proper types. These have been consistent x86 asks. So you end
up with something a bit more than a register packing function.

So to get the x86 acks on these patches, we were going to package them up into
small chunks that do something small (see PATCH Organization section of
coverletter). So we can succinctly show what the TSM subsystem needs, and how
the wrappers are designed for that. 

Ideally, we could get the x86 acks earlier, such that they can be ready to go
when the TSM guest side stuff is ready. Once they have the acks, maybe they get
reformed into a larger series. But the point is for the sake of getting those
x86 patches acked.

Any concerns?

> 
> Everything related to SPDM Should live in attestation subsystem, and
> we are not likely to be having every arch duplicate the object
> "caching" either...

Makes sense.