Re: [RFC PATCH v2 0/4] Add KVM API for confidential guest live migration

[Artem Bityutskiy <dedekind1@gmail.com>]

On Tue, 2026-09-22 at 12:42 +0300, Tony Lindgren wrote:
> 
> > Anyway, if I can get the TDX module to allow dirty tracking independent of
> > migration, we could pick either mechanism, or even implement both and add a
> > TDX-specific ioctl to select which one to use. We could plug either method
> > into the KVM_DIRTY_LOG ioctl - both would work, just differently.
> 
> Note that for TDX write-blocking is an older approach. The non-blocking
> SEAMCALLs were added because of the issues noticed. Both features are not
> usable the same time.

But let me clarify one point: write-blocking (the WP-based mechanism) isn't
broken - it works fine. For fairness:

- MMU-intrusiveness - valid argument.
- It is "older" - not on its own a strong argument. Older does not
  automatically make it categorically worse.

Side note: although I always try to remember that if there is a real need,
we can work with the TDX module architects on the  ABI to reduce that
intrusiveness. I do not see the need yet, though.

> If non-blocking is enabled for a TDX module write-blocking cannot be used.
> Also note that the dirty log scan features depend on non-blocking features
> being enabled.

To make it more pronounced: Tony says the blocking vs. non-blocking TDX
export mode is:

- Global for all TDs, not a per-TD choice.
- Decided at TDX module initialization time, and cannot be changed without
  re-initializing or updating the module. So in practice, it's a kernel
  init time decision.

So my suggestion that both could be implemented and selected via a uAPI is
moot in practice.

Good point, thanks!

Artem.