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/7/26 9:43 PM, Tony Lindgren wrote:
> On Mon, Sep 07, 2026 at 04:32:33PM +0300, Artem Bityutskiy wrote:
>> 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.
> 
> OK


Just sharing an alternate point of view:

The roles are fixed over a migration session. A split ABI is certainly more 
self-describing, but it restates that invariant on every call, and therefore 
also permits it to be contradicted -- a failure mode that does not otherwise
exist. With a single KVM_MIGRATE_CMD and a per-session role recorded once (more 
on that below), there is no need for per-call policing: the role could be 
checked once when the session is established.

Along these lines: it raises a question of whether the MEMORY and VCPU
calls should be coalesced as well into KVM_MIGRATE_MEMORY and KVM_MIGRATE_VCPU.
As posted, direction is implicit for KVM_MIGRATE_CMD but encoded in the ioctl
number for those transfers, so collapsing them would at least make the uAPI
consistent about where direction comes from, and free two ioctls.

>  
>> ...
>>
>> 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.
> 
> Yes the "record and remember" is another option, it could be a sub-command
> something like KVM_MIGRATE_DIRECTION.


Agreed on record-and-remember, with a refinement on scope.

A VM that was migrated in can later be migrated out, so the role is not a
property of the VM -- it has to be recorded per session. SETUP is the call
that starts a migration and runs ahead of all other migration calls, so its
arguments look like the natural place for userspace to state the role; a
separate sub-command would need its own scope rules relative to SETUP.
KVM can then ask the vendor layer whether the requested role is permitted for
this VM -- only it knows the confidential-VM state -- and on success record it
in generic KVM state, where it then selects the export or import callbacks.