Re: [RFC PATCH v2 2/4] KVM: x86: Add optional KVM_CAP_LIVE_MIGRATION and KVM_MIGRATE_CMD

[Artem Bityutskiy <dedekind1@gmail.com>]

On Mon, 2026-09-07 at 15:15 +0200, Jörg Rödel wrote:
> The direction is always the same over a single live migration session, right?
> So it could be a setup flag, on the other hand having separate KVM_EXPORT_CMD
> and KVM_IMPORT_CMD seems to be a cleaner ABI.

Yes, the source stays the source, and the destination stays the destination
for the entire session.

This is a special case of a broader question I keep coming back to:

** How much state should KVM keep about a migration session? **

For direction specifically, we could pass it to KVM on every call and let
KVM stay stateless about it, or KVM could record it once and remember it for
the rest of the session.

But in general. And this is addressed not just to Jörg, but community.

Traditional VM migration is driven by QEMU. KVM provides building blocks
such as dirty page tracking and vCPU state get/set APIs, but it does not
track the overall migration session. The migration session state lives in
QEMU.

Our TDX live migration prototype keeps some per-migration state in KVM,
for example the direction, the migration phase (setup done, started,
paused, and so on). This lets use validate inputs and issue the correct TDX
module seamcalls from KVM.

A different uAPI could shift this balance either way.

In the **extreme** case, we could expose a uAPI for each migration
seamcall. KVM would then just pass inputs and outputs between the TDX
module and QEMU, staying a thin layer with no per-session state. We have
not tried this, but it illustrates the trade-off.

So where is the right boundary for migration state in KVM?

Should KVM manage none of it, or is some state acceptable?

Would be interesting to know what KVM community thinks on this.

Thanks,
Artem.