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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 03, 2026 at 12:48:51AM +0000, Edgecombe, Rick P wrote:
> 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.

It makes complete sense, yes

Maybe I was too specific to say 'very low level'.

Like arch code shouldn't be running the SPDM FSM or doing "caching"
for example, but that doesn't mean it has to be as low level as just
register packing.

> 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. 

I think the lock/unlock is possibly pretty straightforward

I feel the viommu design is coming together well and is looking like
it will go once the three arches agree.

Anything to do with SPDM seems like it will need alot of work to get
the right shared code and flows together, I would be careful trying to
prefetch that too much.

Maybe that helps guide what could go first along with drivers?

> Any concerns?

I don't mind, I'm just hoping we can have stuff in more central
locations and not in arch code..

Jason