qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to Virti


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice
Date: Fri, 31 May 2019 16:36:33 -0300
User-agent: Mutt/1.11.3 (2019-02-01)

On Tue, May 28, 2019 at 10:48:09AM +0800, Yongji Xie wrote:
> On Tue, 28 May 2019 at 02:54, Michael S. Tsirkin <address@hidden> wrote:
> >
> > On Mon, May 27, 2019 at 12:44:46PM +0200, Greg Kurz wrote:
> > > On Fri, 24 May 2019 19:56:06 +0800
> > > Yongji Xie <address@hidden> wrote:
> > >
> > > > On Fri, 24 May 2019 at 18:20, Greg Kurz <address@hidden> wrote:
> > > > >
> > > > > On Mon, 20 May 2019 19:10:35 -0400
> > > > > "Michael S. Tsirkin" <address@hidden> wrote:
> > > > >
> > > > > > From: Xie Yongji <address@hidden>
[...]
> > > > > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void 
> > > > > > *opaque)
> > > > > >      return vdev->broken;
> > > > > >  }
> > > > > >
> > > > > > +static bool virtio_started_needed(void *opaque)
> > > > > > +{
> > > > > > +    VirtIODevice *vdev = opaque;
> > > > > > +
> > > > > > +    return vdev->started;
> > > > >
> > > > > Existing machine types don't know about the "virtio/started" 
> > > > > subsection. This
> > > > > breaks migration to older QEMUs if the driver has started the device, 
> > > > > ie. most
> > > > > probably always when it comes to live migration.
> > > > >
> > > > > My understanding is that we do try to support backward migration 
> > > > > though. It
> > > > > is a regular practice in datacenters to migrate workloads without 
> > > > > having to
> > > > > take care of the QEMU version. FWIW I had to fix similar issues 
> > > > > downstream
> > > > > many times in the past because customers had filed bugs.
> > > > >
> > > >
> > > > If we do need to support backward migration, for this patch, what I
> > > > can think of is to only migrate the flag in the case that guest kicks
> > > > but not set DRIVER_OK. This could fix backward migration in most case.
> > >
> > > You mean something like that ?
> > >
> > > static bool virtio_started_needed(void *opaque)
> > > {
> > >     VirtIODevice *vdev = opaque;
> > >
> > >     return vdev->started && !(vdev->status & VIRTIO_CONFIG_S_DRIVER_OK);
> > > }
> > >
> > > > Not sure if there is a more general approach...
> > > >
> > >
> > > Another approach would be to only implement the started flag for
> > > machine version > 4.0. This can be achieved by adding a "use-started"
> > > property to the base virtio device, true by default and set to
> > > false by hw_compat_4_0.
> >
> > I think this is best frankly.
> >
> 
> Only implement the started flag for machine version > 4.0 might not be
> good because vhost-user-blk now need to use this flag. How about only
> migrating this flag for machine version > 4.0 instead?

Was this implemented?  Is migration from QEMU 4.1 to QEMU 4.0
currently broken?

-- 
Eduardo



reply via email to

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