Re: [PATCH v8 0/9] TDX host: metadata reading tweaks and bug fixes

[Huang, Kai]

On 14/11/2024 11:53 am, Edgecombe, Rick P wrote:
> On Thu, 2024-11-14 at 11:40 +1300, Huang, Kai wrote:
> > > So I think it is not part of the "bare minimum". I don't have any objection
> > > with
> > > it going upstream with rest of this series if it doesn't delay it. But I
> > > want to
> > > make sure we don't have any more confusion that will cause further delays.
> >
> > We have two issues that need to be addressed.  Addressing them could
> > bring the infrastructure that is needed for KVM TDX as well, so this is
> > the "minimal code" given the goal I want to achieve here.
>
> I'm confused by this. "could bring the infrastructure"? What is the "goal I want
> to achieve"?

The goal is mentioned in beginning of the cover letter:

1) address two issues in the current TDX module initialization code, and
2) have an extendable infrastructure which is super easy to read more
   metadata and share with KVM for KVM TDX support (and other kernel
   components for TDX Connect in the future).

> Let me ask it another way, if we drop patches 7 and 8 and pushed them in a later
> series. (say after TDX gets upstream for the sake of this question, but I'm not
> suggesting a schedule). Then what is the consequence to the goal of booting a TD
> on some HW?

The patch to fix the bug is not a dependency of KVM TDX, but it is a 
real issue.  Customers have reported this issue, requested the fix and 
integrated the fix to their environment while we are still in middle of 
upstreaming KVM TDX.

So I don't see anything wrong to include it here.  It also gives us an 
additional user of the new metadata infrastructure.

> I'm not questioning that the patches are in order, or that they should be fixed
> urgently. I'm just trying to make sure we are clear to Dave on why this is all
> needed.

Yeah I'll certainly follow Dave's request.