Re: [PATCH v7 17/22] x86/virt/tdx: Avoid updates during update-sensitive operations

[Dan Williams <djbw@kernel.org>]

Edgecombe, Rick P wrote:
> On Tue, 2026-04-14 at 14:43 -0700, Dan Williams wrote:
> > > tdh_mem_page_add() does a KVM_BUG_ON() if it sees a non-busy error. Imagine
> > > working on this code and considering if it is a valid KVM_BUG_ON()? After
> > > this
> > > patch, the answer is...well sometimes. It depends on the previous modules
> > > specific feature0 bits, an understanding on admins expectations, and the
> > > behavior of some far away code in arch/x86. Gah.
> > 
> > Why would it be variable? The user tried update on a module that the
> > kernel deemed unfit for update. "Doctor, it KVM_BUG_ON()s when I run
> > update".
> 
> The objection is not an unprepared user having an issue. It's that this adds
> burden to the TDX MMU developers who have to keep track of which errors are
> valid and which are not. Doing that is maybe _the_ major challenge for
> maintaining that code, that code is the trickiest of TDX KVM, and we have an
> easy option here to not muddy it further.

I think we are in violent agreement. If a runtime update causes
tdh_mem_page_add() failure then it is simply not a runtime update.

[..]
> > I think the changelog is a bit non-commital trying to be diplomatic
> > about the mess. Simply, Linux wanted the easy button, all runtime
> > updates are safe. Instead, module exported complexity and optionality.
> > KVM voted for one flavor of that optionality to accommodate the module
> > complexity.
> 
> It doesn't pick a flavor.

Oh, you mean in the sense that it proceeds without compat support? Then
yes, agree.

> It tries to handle them both depending on TDX module support. See:
>  
> +	if (tdx_sysinfo.features.tdx_features0 & TDX_FEATURES0_UPDATE_COMPAT)
> +		args.rcx |= TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE;
> 
> So it sounds like you have no objection to only supporting the mode that is easy
> (TDX_SYS_SHUTDOWN_AVOID_COMPAT_SENSITIVE). If we always pass this flag, then the
> TDX MMU developers can have less details to keep in their heads.

Yes. Just pass that flag unconditionally and treat "operand invalid" as
another "can not do a compatible update" case.

> I think Chao took this as an objection to unsupporting
> !TDX_FEATURES0_UPDATE_COMPAT updates, when it really was an objection to the
> kernel trying too hard to help the admin:
> https://lore.kernel.org/kvm/69a0c3d24310_1cc5100d1@dwillia2-mobl4.notmuch/

Drop !TDX_FEATURES0_UPDATE_COMPAT accommodation is the intent. Be mean
to old modules if it saves comments and conditionals in the kernel.