Re: [PATCH v2 2/2] vfio/migration: Make VFIO migration non-experimental

[Cédric Le Goater]

On 6/28/23 16:51, Joao Martins wrote:
> On 28/06/2023 13:54, Cédric Le Goater wrote:
> > On 6/28/23 09:31, Avihai Horon wrote:
> > > The major parts of VFIO migration are supported today in QEMU. This
> > > includes basic VFIO migration, device dirty page tracking and precopy
> > > support.
> > >
> > > Thus, at this point in time, it seems appropriate to make VFIO migration
> > > non-experimental: remove the x prefix from enable_migration property,
> > > change it to ON_OFF_AUTO and let the default value be AUTO.
> > >
> > > In addition, make the following adjustments:
> > > 1. When enable_migration is ON and migration is not supported, fail VFIO
> > >      device realization.
> > > 2. When enable_migration is AUTO (i.e., not explicitly enabled), require
> > >      device dirty tracking support. This is because device dirty tracking
> > >      is currently the only method to do dirty page tracking, which is
> > >      essential for migrating in a reasonable downtime. Setting
> > >      enable_migration to ON will not require device dirty tracking.
> > > 3. Make migration error and blocker messages more elaborate.
> > > 4. Remove error prints in vfio_migration_query_flags().
> > > 5. Rename trace_vfio_migration_probe() to
> > >      trace_vfio_migration_realize().
> > >
> > > Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> >
> >
> > We should rework the return value of most of the routines called by
> > vfio_migration_realize() and simply use a bool. I think Zhenzhong is
> > working it.
> >
> > Zhenzhong,
> >
> > When you resend v4 of the "VFIO migration related refactor and bug fix"
> > series, please rebase on this patch since it should be merged.
>
> This, and his switchover-ack series from Avihai that preceeds it.
>
> Perhaps it might be easier to point to your tree:branch where you are queueing
> all the patches?

Sure.

I track QEMU patches for various subsystems under :

 https://github.com/legoater/qemu

 
VFIO candidates are under :

  https://github.com/legoater/qemu/tree/vfio-8.1

This is a wip tree, patches come and go. It contains the VFIO patches of
the day/week, good for testing new ideas and checking CI.


The vfio-next branch contains what I am 90% sure to send upstream :

 https://github.com/legoater/qemu/tree/vfio-next

which I rebase on master and update with new proposals and new tags.

Beware, both are git push forced branches. Only master is not.


Cheers,

C.