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

[Cédric Le Goater]

[ Cc: Shameer ]


> > > I see ON_OFF_AUTO_ON as a way to abort the machine startup while
> > > ON_OFF_AUTO_AUTO would let it run but block migration.
> >
> > Agreed.  There's a little bit of redundancy between the device-level
> > "enable-migration=on" option and the global "-only-migratable" option
> > relative to preventing machine startup, but it also doesn't make sense
> > to me if the device-level option let realize complete successfully if
> > the device doesn't support or fails migration setup.  So I think we'd
> > generally rely on using the -only-migratable option with the default
> > ON_OFF_AUTO_AUTO value, allow the ON_OFF_AUTO_ON value to enable
> > dis-recommended support, and live with the redundancy that it should
> > also cause the device realize to fail if migration is not supported.
> > Thanks,
> >
> > Alex
>
> OK.
>
> When enable_migration=AUTO we allow blockers.
> When enable_migration=ON we don't allow blockers and instead prevent 
> realization of VFIO device.
>
> Regarding device dirty tracking, we keep current behavior, right?
> That is:
> When enable_migration=AUTO we block migration if device dirty tracking is not 
> supported.
> When enable_migration=ON we allow migration even if device dirty tracking is not 
> supported > (in which case DMA-able memory will be perpetually dirtied).

Yes. That's how I understand it. This is what you initially proposed.

The default behavior is to allow migration only if the host kernel
driver supports dirty tracking.

We have a way to run and migrate a machine with a device not supporting
dirty tracking. Only Hisilicon is in that case today. May be there are
plans to add dirty tracking support ?

Thanks,

C.