Message-ID: <1e00cac3164ea0f20ba2cd68e3f4790c6f1da091.camel@intel.com>
Date: Wed, 13 Nov 2024 22:25:37 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>, "bp@...en8.de"
	<bp@...en8.de>, "peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Williams, Dan J" <dan.j.williams@...el.com>
CC: "nik.borisov@...e.com" <nik.borisov@...e.com>, "Hunter, Adrian"
	<adrian.hunter@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH v8 0/9] TDX host: metadata reading tweaks and bug fixes

On Thu, 2024-11-14 at 00:57 +1300, Kai Huang wrote:
> This series replaces the existing TDX module metadata reading code with
> a new auto-generated global metadata infrastructure to:
> 
> 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).
> 
> And the reason that we need a new global metadata infrastructure is the
> current one can only read TDMR related metadata fields and it is not
> extendable to read more metadata fields, which is required to address
> both 1) and 2) above.
> 
> Specifically, below two issues in the current module initialization code
> need to be addressed:
> 
> 1) Module initialization may fail on some large systems (e.g., with 4 or
>    more sockets) [1].

Earlier Dave asked:
"What is your goal?  What is the bare minimum amount of code to get there?"

I think the goal right now is to get the critical dependencies for KVM basic TD
boot support upstream. Basically the bare minimum to do something useful. Since
unlike the rest of the pending pre-reqs, this series will need to go through
Linus' tree and back down to KVM's before we can drop the kvm-coco-queue copy,
this part is a little more urgent. At least from an order of operations
perspective.

I looked at this bug, and it seems like if this is not fixed then TDX will not
be usable in some TDX supporting platforms. Is that right? So the consequence of
not having this would be that when KVM support lands not all TDX capable HW can
use TDX. But it won't make the TDX KVM support totally useless. And otherwise
the error condition is handled cleanly in the upstream code.

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.

> 2) Some old modules can clobber host's RBP when existing from the TDX
>    guest, and currently they can be initialized successfully.  We don't
>    want to use such modules thus we should just fail to initialize them
>    to avoid memory/cpu cycle cost of initializing TDX module [2].

I think we need RBP MOD for basic support, or it may cause crashes when we start
booting TDs.

Does all that seem correct?

> 
> The first 6 patches introduce the new auto-generated global metadata
> infrastructure (which is auto-generated using a script [3]), and the
> rest patches address the above two issues.

Powered by blists - more mailing lists