Kai Huang wrote:
> Currently the kernel doesn't print any information regarding the TDX
> module itself, e.g. module version. In practice such information is
> useful, especially to the developers.
>
> For instance, there are a couple of use cases for dumping module basic
> information:
>
> 1) When something goes wrong around using TDX, the information like TDX
> module version, supported features etc could be helpful [1][2].
>
> 2) For Linux, when the user wants to update the TDX module, one needs to
> replace the old module in a specific location in the EFI partition
> with the new one so that after reboot the BIOS can load it. However,
> after kernel boots, currently the user has no way to verify it is
> indeed the new module that gets loaded and initialized (e.g., error
> could happen when replacing the old module). With the module version
> dumped the user can verify this easily.
For this specific use case the kernel log is less useful then finding
a place to put this in sysfs. This gets back to a proposal to have TDX
instantiate a "tdx_tsm" device which among other things could host this
version data.
The kernel log message is ok, but parsing the kernel log is not
sufficient for this update validation flow concern.
[..]
> +static void print_basic_sys_info(struct tdx_sys_info *sysinfo)
> +{
> + struct tdx_sys_info_features *features = &sysinfo->features;
> + struct tdx_sys_info_version *version = &sysinfo->version;
> +
> + /*
> + * TDX module version encoding:
> + *
> + * <major>.<minor>.<update>.<internal>.<build_num>
> + *
> + * When printed as text, <major> and <minor> are 1-digit,
> + * <update> and <internal> are 2-digits and <build_num>
> + * is 4-digits.
> + */
> + pr_info("Initializing TDX module: %u.%u.%02u.%02u.%04u (build_date %u), TDX_FEATURES0 0x%llx\n",
> + version->major, version->minor, version->update,
> + version->internal, version->build_num,
> + version->build_date, features->tdx_features0);
I do not see the value in dumping a raw features value in the log.
Either parse it or omit it. I would leave it for the tdx_tsm device to
emit.
