Re: TDX migration model

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

On Thu, Nov 05, 2026 at 06:00:41PM -0800, Kishen Maloor wrote:
> On 11/5/26 8:42 AM, Serge E. Hallyn wrote:
> > On Thu, Nov 05, 2026 at 05:59:01PM +0200, Artem Bityutskiy wrote:
> >> On Thu, 2026-11-05 at 08:58 -0600, Serge Hallyn (AMD) wrote:
> >>> ...
> >>> So, looking at the section '### How the Setup Session Works', is it safe
> >>> to assume that you are using the qemu migration fd for the message
> >>> transfers?  So basically qemu loops over KVM_MIGRATE_SETUP calls, which
> >>> ...
> >> Yes, that's the flow. I’m not sure about the migration fd part, I believe we
> >> pass the setup session data via ioctl buffers. I am sure Kishen will can
> >> clarify.
> > 
> > If you mean pass via ioctl buffers from tdx->kvm-> back to qemu, which passes
> > it over the migration fd to the other side, then that's what I expected.
> > Othewise I'll be interested to the details :)
> 
> Hi Serge,
> 
> Your understanding is right. Migration setup requires a handshake of some sort
> between the source and destination. So the messages KVM_MIGRATE_SETUP returns
> are transferred over QEMU's migration channel to the other side and processed
> by a matching call.

Serge, on the QEMU side, we have been enabling the return-path early for
the key exchange before migration is active. Not sure if the key exchange
can be done using a VMState, possibly could be if we can ensure it happens
before the migration is active.

For the migration related commands, looks like we can just make the
KVM_EXPORT_CMD and KVM_IMPORT_CMD subcommands a bit more finer grained and
then drop the vendor flags until needed:

#define KVM_MIGRATE_EXCHANGE_KEYS	0 (New, was KVM_MIGRATE_SETUP and a flag)
#define KVM_MIGRATE_SETUP		1 (Migrates the immutable state)
#define KVM_MIGRATE_ITERATION		2 (Start a new pre-copy round)
#define KVM_MIGRATE_ITERATION_FINAL	3 (New, last pre-copy round before pause)
#define KVM_MIGRATE_PAUSE		4 (New, split from old STOP_AND_COPY)
#define KVM_MIGRATE_MUTABLE_STATE	5 (New, split from old STOP_AND_COPY)
#define KVM_MIGRATE_START_DESTINATION	6 (New, split from old STOP_AND_COPY)
#define KVM_MIGRATE_START_POSTCOPY	7 (New, could return -EOPNOTSUPP for now?)
#define KVM_MIGRATE_ABORT		8
#define KVM_MIGRATE_END			9

For the above PAUSE is four the source only. START_DESTINATION is for both
source and destination as source exports a start token for the destination.
START_POSTCOPY is not implemented but would be destination only when
implemented. ABORT is allowed at any point.

Any other subcommands needed at this point?

Then for handling the results, the following seems to simplify things a bit:

- Results are copied back only on success, vendor error is returned as is

- Import is all or nothing, vendor code resumes on interruptions

- For memory transfer, a GFN can only be transferred once per round,
  duplicate import attempt returns -EINVAL

Regards,

Tony