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