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

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

On Mon, Sep 14, 2026 at 05:14:32PM -0700, Kishen Maloor wrote:
> On 9/10/26 9:23 PM, Tony Lindgren wrote:
> > On Thu, Sep 10, 2026 at 06:40:04PM -0700, Kishen Maloor wrote:
> >> 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.
> > 
> > So we could add a SETUP subcommand SET_ROLE or SET_INCOMING.
> It might be better to pass the role as a parameter of the SETUP call
> rather than a separate SET_ROLE call.
> A separate SET_ROLE would bring its own ordering rules relative to the
> other SETUP sub-commands. 

OK a flag for SETUP sounds good to me. SETUP is needed anyways for each
migration session.
 
> The specific role (src or dst) still needs someplace to go, and flags is
> already the sub-command selector. An option is to carve out room in
> the __u32 reserved field to carry a role argument, something
> like 0=unset, 1=src, 2=dest so KVM can verify that a role was indeed set.

To me it seems that 0=src can be the natural default starting point, I
don't think we need 0=unset.

> It could further be written into a generic KVM struct (kvm_arch or kvm) which
> could be queried on KVM_TRANSFER_MEMORY, etc. to identify the relevant
> callback.

Yeah eventually some generic place for it would be nice. But that's easy
to add later on too.