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

[Tony Lindgren <tony.lindgren@linux.intel.com>]

On Tue, Sep 22, 2026 at 02:54:29PM +0300, Artem Bityutskiy wrote:
> 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.

Correct. And I'm of course a bit biased on the write-blocking migration
after tinkering with it some so please excuse me.

For reference, there are earlier WIP patches from 2023 for TDX using the
write-blocking at [0] and [1] below. While the write-blocking itself seems
fairly straight forward, it's interaction with live migration is complicated
to unblock pages.

You may want to add a VM exit and TDX module unblock for each 4K page to the
list for the TDX write-blocking migration.
 
> 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.

Yup. If somebody really needs it, selecting write-blocking migration could
be a module param.

[0] https://github.com/intel-staging/tdx/commit/d6c63ebf463297a076984fe248aabeba0fa58864
[1] https://github.com/intel-staging/tdx/commit/782649ab74c1b3f05df7e38d5fc8e3f907a9394e