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

[Kishen Maloor <kishen.maloor@intel.com>]

On 9/9/26 11:33 PM, Tony Lindgren wrote:
> On Wed, Sep 09, 2026 at 06:11:11PM -0700, Kishen Maloor wrote:
> ...
>>
>> As mentioned above, that is a destination launch time directive that we needn't
>> conflate with a migration/transfer session role.
> 
> It's still the same role though. Yes we can set it on init, but would
> be nice to have some generic way to do it for qemu -incoming.

I'd separate these.

On the role: it seems we agree on recording roles per-session. My only point
then is that a VM created through the delayed_init flow doesn't additionally
need a destination role recorded for it if SETUP will assert one when the
migration is kicked off.

On generic plumbing for -incoming: is this about KVM_TDX_INIT_VM_F_DELAY_INIT?
A generic mechanism would make sense to me if the flag were consumed by generic
KVM code, but that isn't the case here. Userspace has to make a
vendor-specific VM-init call like KVM_TDX_INIT_VM anyway, with the flag passed
on that call. So I'm not sure what a generic version would add, unless you have
something else in mind.

> Just brainstorming.. I wonder if we need two things though. A source vs
> destination role. And then at some point possibly later on also a data
> transfer direction enumeration similar to what Linux has in
> include/linux/dma-direction.h.
> 
> We already need to make use of the QEMU return-path for the migration key
> exchange. What if some hardware needs to make use of KVM_TRANSFER_MEMORY
> from source to destination, and after that back from destination to source
> to ack the transfer? Sure this is just speculation, I'm not aware of this
> need right now.
> 
> In any case with handling the source vs destination role, the enumeration
> for data direction can be added to the transfer flags later on as needed.
> No need to try to stuff the data direction flag there until really needed.

Agree on deferring such an enumeration. More generally though, the session
role determines which operations are permitted, and it seems like vendor code
could be expected to handle those in context.

The TDX architecture already has a destination-to-source example:
TDH.IMPORT.ABORT emits an abort token on the destination that
TDH.EXPORT.ABORT consumes on the source. So KVM on the source would dispatch
to its export-abort path and let the vendor layer decide what to do with
the buffer. This doesn't require a direction flag.