Message ID | cover.1731318868.git.kai.huang@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | TDX host: metadata reading tweaks, bug fix and info dump | expand |
On 11/11/24 02:39, Kai Huang wrote: > This series does necessary tweaks to TDX host "global metadata" reading > code to fix some immediate issues in the TDX module initialization code, > with intention to also provide a flexible code base to support sharing > global metadata to KVM (and other kernel components) for future needs. Could we please just limit this to the bug fix and the new TD metadata infrastructure? Let's not mix it all up with the debugging printk()s.
On Mon, 2024-11-11 at 12:33 -0800, Dave Hansen wrote: > On 11/11/24 02:39, Kai Huang wrote: > > This series does necessary tweaks to TDX host "global metadata" reading > > code to fix some immediate issues in the TDX module initialization code, > > with intention to also provide a flexible code base to support sharing > > global metadata to KVM (and other kernel components) for future needs. > > Could we please just limit this to the bug fix and the new TD metadata > infrastructure? Let's not mix it all up with the debugging printk()s. It also has a patch to fail module initialization when NO_MOD_BBP feature is not support. Just want to confirm, do you want to remove the code to: - print CMRs; - print TDX module versoin; ? Then I will need to: - remove "printing CMRs" in patch 7 ("x86/virt/tdx: Trim away tail null CMRs"). - remove patch 10 ("x86/virt/tdx: Print TDX module version").
On 11/11/24 12:49, Huang, Kai wrote: > It also has a patch to fail module initialization when NO_MOD_BBP feature is not > support. > > Just want to confirm, do you want to remove the code to: > > - print CMRs; > - print TDX module versoin; What is your goal? What is the bare minimum amount of code to get there?
On Mon, 2024-11-11 at 13:00 -0800, Hansen, Dave wrote: > On 11/11/24 12:49, Huang, Kai wrote: > > It also has a patch to fail module initialization when NO_MOD_BBP feature is not > > support. > > > > Just want to confirm, do you want to remove the code to: > > > > - print CMRs; > > - print TDX module versoin; > > What is your goal? What is the bare minimum amount of code to get there? The goal is to get everything that KVM TDX needs merged, plus the bug fix. KVM TDX needs the new metadata infrastructure and the NO_MOD_BRP patch, so yeah only printing CMRs and TDX module version are not needed. I'll remove them in the next version.
On Mon, 2024-11-11 at 21:28 +0000, Huang, Kai wrote: > On Mon, 2024-11-11 at 13:00 -0800, Hansen, Dave wrote: > > On 11/11/24 12:49, Huang, Kai wrote: > > > It also has a patch to fail module initialization when NO_MOD_BBP feature is not > > > support. > > > > > > Just want to confirm, do you want to remove the code to: > > > > > > - print CMRs; > > > - print TDX module versoin; > > > > What is your goal? What is the bare minimum amount of code to get there? > > The goal is to get everything that KVM TDX needs merged, plus the bug fix. > > KVM TDX needs the new metadata infrastructure and the NO_MOD_BRP patch, so yeah > only printing CMRs and TDX module version are not needed. > > I'll remove them in the next version. I removed the "version" part in the 'tdx_global_metadata.py' script in order to remove the code which reads TDX module version from the auto-generated code. For the sake of having a lore link of the script that I used in the new version, I attached the updated script here. It just got "version" part removed thus is not interesting to read. And Sorry I didn't provide enough info about the "goal" in my previous reply: The goal of this series is to provide a new TDX 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). 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. The minimal code to achieve this goal is to remove the code which prints TDX module version and CMR info in this series. After removing them, the fist 6 patches in this series introduce the new metadata infrastructure, and the rest patches address the two above issues.