Re: [PATCH 6/6] x86/virt/tdx: Re-initialize the extensions on runtime TDX module update
Xu Yilun <[email protected]>
| Newsgroups | org.kernel.vger.kvm,dev.linux.lists.linux-coco,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <ao23M9LG9paVfKsT@yilunxu-OptiPlex-7050> |
On Sat, Aug 22, 2026 at 12:01:08AM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-08-21 at 11:29 +0800, Xu Yilun wrote:
> > Runtime TDX module update introduces a mechanism to update the module
> > firmware while preserving and restoring TDX operations. As part of the
> > restoration process, the host must re-initialize the extensions to
> > restore their functionality.
> >
> > Linux runs the updates in stop_machine() context, which prevents memory
> > allocation. This introduces a hard restriction that the updated TDX
> > environment must not consume more memory for the extensions.
> >
> > The impact of the memory allocation restriction can be mitigated by
> > another requirement. Runtime updates should keep the add-on features
> > unchanged across updates, so that existing TDX users can continue to
> > operate without disruption. This requirement minimizes the chance of
> > increased memory demand.
> >
>
> Above it says it's a "hard restriction that the updated TDX environment must not
> consume more memory", but here it says if everything is left the same, it only
> minimizes the chances. Can it be consistent?
I made a new version:
Linux runs the updates in stop_machine() context, which prevents memory
allocation. This introduces a hard restriction that the compatible
update must not consume more memory for the extensions.
This restriction has no additional impact on the kernel. Recall that
runtime updates should keep the add-on features unchanged across
updates, so that existing TDX users can continue to operate without
disruption. This guarantees that the kernel will never introduce
additional memory requirement for the extensions.
[...]
> > +static int update_tdx_module_extensions(void)
> > +{
> > + if (!tdx_sysinfo.ext.ext_required)
> > + return 0;
> > +
> > + return tdx_ext_init();
> > +}
> > +
> > static __init int init_tdx_module(void)
> > {
> > int ret;
> > @@ -1532,6 +1545,10 @@ int tdx_module_run_update(void)
> > */
> > WARN_ON_ONCE(ret);
> >
> > + ret = update_tdx_module_extensions();
> > + if (ret)
> > + return ret;
> > +
>
> Above it has:
> /*
> * Only fails if there is something unexpected
> * and severely wrong with the module.
> */
> WARN_ON_ONCE(ret);
>
> Is the tdx_ext_init() possible to fail here?
Yes. E.g. when more memory is required.
> Otherwise it seems unclear why to
> only not handle get_tdx_sys_info_version() failure. Maybe at least group it with
> the other ones that are allowed to fail.
Yes, I can move it right under tdh_sys_update().
>
> > tdx_module_state.initialized = true;
> > return 0;
> > }
>