Re: [PATCH 6/9] vfio/migration: Implement VFIO migration protocol v2

[Avihai Horon]

On 5/23/2022 9:14 PM, Joao Martins wrote:
> External email: Use caution opening links or attachments
>
>
> On 5/12/22 16:43, Avihai Horon wrote:
> > Replace the current VFIO migration protocol v1 implementation with a new
> > implementation corresponding to VFIO migration protocol v2.
> >
> > The main changes are:
> > - VFIO device state is now represented as a finite state machine instead
> >    of a bitmap.
> >
> > - Migration interface with kernel is now done using VFIO_DEVICE_FEATURE
> >    ioctl and normal read() and write() instead of the migration region.
> >
> > - As VFIO migration protocol v2 currently doesn't support the pre-copy
> >    phase of migration, .save_live_pending and .save_live_iterate handlers
> >    plus pre-copy relevant code are removed.
> >
> > Detailed information about VFIO migration protocol v2 and difference
> > compared to v1 can be found here [1].
> >
> > [1]
> > https://lore.kernel.org/all/20220224142024.147653-10-yishaih@nvidia.com/
> >
> > Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> > ---
> >   hw/vfio/common.c              |  21 +-
> >   hw/vfio/migration.c           | 628 +++++++---------------------------
> >   hw/vfio/trace-events          |   9 +-
> >   include/hw/vfio/vfio-common.h |   8 +-
> >   4 files changed, 153 insertions(+), 513 deletions(-)
> This looks like a fairly big patch, though more than 70% of it is removing
> code. Perhaps you could split it into adding v2 and removing v1 afterwards, 
> rather
> than a single replacement patch? It's just a suggestion anyhow, to hopefully 
> ease
> analysis of the new additions. The removal looks to muddle a tiny bit.
>
> I don't wanna throw you into potentially unnecessary work should maintainers 
> disagree,
> so here's an attempt:
>
>          https://github.com/jpemartins/qemu/commits/for-avihai
Ah, nice idea, thanks! I was afraid this patch would be too cluttered.

Alex, do you want me to split this patch in a similar manner as Joao 
suggested? and maybe add v1 prefixes to existing functions instead of v2 
to new functions?

> If you apply your series on top of the same base commit (78ac2eebbab9) you 
> should be able
> to compare both branches.
>
> I haven't found yet any particular flaws in your new logic (but will reply back 
> if I find
> any).

Sure, thanks!