On Tue, Oct 29, 2024 at 01:05:04PM -0400, Peter Xu wrote: > But I'm not sure whether that's a concern at all for Libvirt, if what > Libvirt currently does is having separate "migrate-set-*" commands prior to > the "migrate". I may have overlooked the real issue behind on how that > could complicate Libvirt. > > > > > Rather than MigrationState become a singleton, I'd really encourage > > trying to see if we can fix the lifecycle design problems, so that > > we have a clear beginning & end of the migration operation, with the > > state discarded at the end, such that every future migrate starts > > from a clean base. > > I assume it implies the join() path as a start. As long as we're ok we > risk slow quits of QEMU, as I would expect bug reports coming afterwards, > we could try. I believe there's no way we can resolve all such issues in > one shot. I doubt whether some of those can be too tricky so we may wish > to go back at some point, spending too much effort but without a direct > benefit yet so far. > > Meanwhile we still have the immediate concern that current_migration can > points to freed memory right now with QEMU master branch. That's simply > wrong.
Yeah, if we're accessing freed memory, that's a segv/abrt danger, and needs fixing quickly. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
