On 30.08.2024 20:55, Fabiano Rosas wrote:
"Maciej S. Szmigiero" <m...@maciej.szmigiero.name> writes:
From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com>
Since device state transfer via multifd channels requires multifd
channels with packets and is currently not compatible with multifd
compression add an appropriate query function so device can learn
whether it can actually make use of it.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
Out of curiosity, what do you see as a blocker for migrating to a file?
We would just need to figure out a mapping from file offset some unit of
data to be able to write in parallel like with ram (of which the page
offset is mapped to the file offset).
I'm not sure whether there's a point in that since VFIO devices
just provide a raw device state stream - there's no way to know
that some buffer is no longer needed because it consisted of
dirty data that was completely overwritten by a later buffer.
Also, the device type that the code was developed against - a (smart)
NIC - has so large device state because (more or less) it keeps a lot
of data about network connections passing / made through it.
It doesn't really make sense to make snapshot of such device for later
reload since these connections will be long dropped by their remote
peers by this point.
Such snapshotting might make more sense with GPU VFIO devices though.
If such file migration support is desired at some later point then for
sure the whole code would need to be carefully re-checked for implicit
assumptions.
Thanks,
Maciej
