"Maciej S. Szmigiero" <m...@maciej.szmigiero.name> writes: > 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, let's keep those arguments in mind, maybe we put them in a doc somewhere so we remember this in the future. > > Thanks, > Maciej
