On Wed, Oct 23, 2024 at 11:14:24AM -0400, Peter Xu wrote:
> On Wed, Oct 23, 2024 at 11:30:14AM +0300, Avihai Horon wrote:
> >
> > On 22/10/2024 19:07, Peter Xu wrote:
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > Migration object can be freed before some other
On Wed, Oct 23, 2024 at 11:30:14AM +0300, Avihai Horon wrote:
>
> On 22/10/2024 19:07, Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > Migration object can be freed before some other device codes run, while we
> > do have a bunch of migration helpers expo
On 22/10/2024 19:07, Peter Xu wrote:
External email: Use caution opening links or attachments
Migration object can be freed before some other device codes run, while we
do have a bunch of migration helpers exported in migration/misc.h that
logically can be invoked at any time of QEMU, even du
On Tue, Oct 22, 2024 at 06:11:19PM +0200, Cédric Le Goater wrote:
> On 10/22/24 18:07, Peter Xu wrote:
> > Migration object can be freed before some other device codes run, while we
> > do have a bunch of migration helpers exported in migration/misc.h that
> > logically can be invoked at any time o
On 10/22/24 18:07, Peter Xu wrote:
Migration object can be freed before some other device codes run, while we
do have a bunch of migration helpers exported in migration/misc.h that
logically can be invoked at any time of QEMU, even during destruction of a
VM.
Make all these functions safe to be
Migration object can be freed before some other device codes run, while we
do have a bunch of migration helpers exported in migration/misc.h that
logically can be invoked at any time of QEMU, even during destruction of a
VM.
Make all these functions safe to be called, especially, not crashing afte
