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