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 Wed, Sep 23, 2026 at 10:53:28PM -0700, Kishen Maloor wrote:
> On 9/22/26 11:04 PM, Tony Lindgren wrote:
> > On Tue, Sep 22, 2026 at 05:38:43PM -0700, Kishen Maloor wrote:
> >> On 9/21/26 10:25 PM, Tony Lindgren wrote:
> >>> On Mon, Sep 21, 2026 at 08:57:45PM -0700, Kishen Maloor wrote:
> >>>> On 9/20/26 11:52 PM, Tony Lindgren wrote:
> >>>>> Then for KVM tracking the role, I don't think we need it with the two
> >>>>> above. The role tracking can always be added if really needed. Any other
> >>>>> opinions on this one?
> >>>>
> >>>> I do think it's useful for generic KVM to track this role (1 byte).
> >>>> - It lets _TRANSFER_ style calls dispatch directly to import or export 
> >>>>   callbacks based on the role.
> >>>> - Even if we don't adopt the _TRANSFER_ style, it enables generic KVM to
> >>>>   reject mismatched calls, e.g., KVM_EXPORT_MEMORY on a destination.
> >>>
> >>> Having KVM do generic checks on the calls is a good idea. There might be
> >>> a simpler way of handling it though. Rather than having KVM track the
> >>> migration state, how about we add a function to check for the migration
> >>> session state from the vendor code?
> >>>
> >>> So something like this for the states you suggested earlier:
> >>>
> >>> enum kvm_lmstate {
> >>> 	KVM_LM_NONE,
> >>> 	KVM_LM_SOURCE,
> >>> 	KVM_LM_DESTINATION,
> >>> };
> >>>
> >>> With something like this to get the state from the vendor code:
> >>>
> >>> enum kmv_lmstate kvm_arch_get_lmstate(struct kvm *);
> >>>
> >>> For x86 it would end up calling kvm_x86_call(get_lmstate)(kvm) and for
> >>> the TDX specific case tdx_get_lmstate().
> >>
> >> How is this simpler? It trades one byte in a KVM struct for a new generic
> >> enum, a new kvm_arch_get_lmstate(), a new kvm_x86_ops entry, and a vendor
> >> implementation per vendor, plus a cross-layer call on every command just
> >> to learn the role.
> >> Directly checking a stored byte (0=unset/1=src/2=dst) seems simplest, no?
> > 
> > It would avoid dragging KVM into the "track the migration state" business
> > at least for now.
> > 
> > I guess the question in general is: What does KVM need to do with the
> > migration role beyond generic checks on the migration related calls?
> 
> I haven't thought of any other uses for it. But if we do want those generic
> checks, I'd still lean toward the stored byte.

We can easily add the KVM role later on if real KVM generic need for
carrying the migration role comes up. We can just have the vendor code
do the checks for now.