qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/4] QOM: Singleton interface


From: Daniel P . Berrangé
Subject: Re: [PATCH 0/4] QOM: Singleton interface
Date: Tue, 29 Oct 2024 17:17:47 +0000
User-agent: Mutt/2.2.12 (2023-09-09)

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]