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 21, 2026 at 12:24:26PM +0300, Tony Lindgren wrote:
> On Mon, Sep 21, 2026 at 09:52:42AM +0300, Tony Lindgren wrote:
> > On Sun, Sep 20, 2026 at 05:13:10PM -0700, Kishen Maloor wrote:
> > > On 9/17/26 10:58 PM, Tony Lindgren wrote:
> > > > So looks like we have tree things to consider: userspace set migration
> > > > role, the hardware state, and transfer direction.
> > > 
> > > Two of those three I agree with: userspace passes the role at SETUP, and
> > > the vendor implementation tracks the hardware state. It's the per-transfer
> > > direction I don't think we need.
> > 
> > Ack on the userspace passing the role at SETUP and vendor implementation
> > tracking the hardware state.
> > 
> > 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?
> > 
> > The transfer direction is there with the EXPORT/IMPORT naming. Maybe
> > just let's keep that naming for easier readability rather than try to 
> > switch to TRANSFER style naming. No transfer direction flag needed.
> 
> Looking at include/linux/dmaengine.h again, the transfer specific
> direction is depreated.. So to follow the the dmaengine analogy, I now
> agree that migration SETUP is the place to set the transfer direction
> like you're suggesting. And so it seems the role at SETUP and the vendor
> implementation tracking the hardware state is all we need.

Sorry above I meant "SETUP is the place to set the role", not the
direction.
 
> The EXPORT/IMPORT vs TRANFER naming both work for me. I find the
> EXPORT/IMPORT easier to read, and I think Jörg also seemed to like
> that naming better.

And KVM is using KVM_GET/SET_REGS type ioctls, not TRANSFER. Also, I
think EXPORT/IMPORT is better naming than GET/SET here as we export
into an encrypted blob.