qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 0/5] virtio-9p: hotplug and migration support


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3 0/5] virtio-9p: hotplug and migration support
Date: Tue, 20 Oct 2015 22:39:41 +0300

On Tue, Oct 20, 2015 at 08:00:53PM +0200, Greg Kurz wrote:
> On Tue, 20 Oct 2015 15:53:08 +0300
> "Michael S. Tsirkin" <address@hidden> wrote:
> 
> > On Tue, Oct 20, 2015 at 11:16:40AM +0200, Greg Kurz wrote:
> > > We already have a blocker to prevent migration of an active virtio-9p 
> > > device.
> > > But in fact, there is no migration support at all for 9p, even if the 
> > > device
> > > is considered to be quiescent (when the VirtFS share is not mounted): 
> > > migration
> > > succeeds but the device is lost in the restarted guest.
> > > Hotunplug of a virtio-9p device is not supported either (no unrealize 
> > > handler)
> > > and leads to a QEMU crash on the source node, if one unplugs and migrates.
> > > 
> > > This series tries to fix that and brings hotplug and migration support of
> > > *quiescent* virtio-9p devices.
> > > 
> > > v2->v3:
> > >  - renamed QDEV handler @unpluggable to @unplug_is_blocked (patches 2/5
> > >    and 3/5)
> > > 
> > > v1->v2:
> > >  - introduced unplug blocker (patches 2/5 and 3/5)
> > >  - moved fixes to separate patches (see individual changelogs)
> > 
> > I have some doubts about how hotunplug is handled, but migration
> > looks ok.
> > Is there a dependency, or can I just pick savevm things meanwhile?
> > 
> 
> Well... you can drop the unplug blocker patches (2/5 and 3/5) but the
> savevm patch (5/5) modifies a function introduced by the unrealize
> patch (4/5):
> 
> @@ -146,6 +157,7 @@ static void virtio_9p_device_unrealize(DeviceState *dev, 
> Error **errp)
>      v9fs_release_worker_threads();
>      g_free(s->ctx.fs_root);
>      g_free(s->tag);
> +    unregister_savevm(dev, "virtio-9p", s);
>      virtio_cleanup(vdev);
>  }
> 
> and not having an unrealize handler calling unregister_savevm() means
> unplug will succeed and leave a dangling pointer in the vm_change_state
> list... This causes a systematic crash of the source QEMU when attempting
> a migration.

OK ... could you pls re-arrange it so that savevm can be applied first?

> > > ---
> > > 
> > > Greg Kurz (5):
> > >       virtio-9p-coth: fix init function
> > >       qdev: add the @unplug_is_blocked handler
> > >       virtio-9p: block hot-unplug when device is active
> > >       virtio-9p: add unrealize handler
> > >       virtio-9p: add savem handlers
> > > 
> > > 
> > >  hw/9pfs/virtio-9p-coth.c   |   22 ++++++++++++++++++----
> > >  hw/9pfs/virtio-9p-coth.h   |    2 ++
> > >  hw/9pfs/virtio-9p-device.c |   24 ++++++++++++++++++++++++
> > >  hw/9pfs/virtio-9p.c        |   14 ++++++++++++++
> > >  hw/9pfs/virtio-9p.h        |    2 ++
> > >  hw/core/qdev.c             |    4 ++++
> > >  hw/s390x/virtio-ccw.c      |    8 ++++++++
> > >  hw/virtio/virtio-pci.c     |    8 ++++++++
> > >  include/hw/qdev-core.h     |    4 ++++
> > >  9 files changed, 84 insertions(+), 4 deletions(-)
> > 



reply via email to

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