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 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.

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.