Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1277597

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

From "Michael S. Tsirkin" <mst@redhat.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date 2015-11-25 17:40 +0100
Message-ID <qyLgT-jU-63@gated-at.bofh.it> (permalink)
References (2 earlier) <qytjZ-56r-11@gated-at.bofh.it> <qyBhw-1WU-5@gated-at.bofh.it> <qyHmV-6e1-3@gated-at.bofh.it> <qyKNR-9k-47@gated-at.bofh.it> <qyL7d-gt-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Nov 25, 2015 at 08:24:38AM -0800, Alexander Duyck wrote:
> >> Also, assuming you just want to do ifdown/ifup for some reason, it's
> >> easy enough to do using a guest agent, in a completely generic way.
> >>
> >
> > Just ifdown/ifup is not enough for migration. It needs to restore some PCI
> > settings before doing ifup on the target machine
> 
> That is why I have been suggesting making use of suspend/resume logic
> that is already in place for PCI power management.  In the case of a
> suspend/resume we already have to deal with the fact that the device
> will go through a D0->D3->D0 reset so we have to restore all of the
> existing state.  It would take a significant load off of Qemu since
> the guest would be restoring its own state instead of making Qemu have
> to do all of the device migration work.

That can work, though again, the issue is you need guest
cooperation to migrate.

If you reset device on destination instead of restoring state,
then that issue goes away, but maybe the downtime
will be increased.

Will it really? I think it's worth it to start with the
simplest solution (reset on destination) and see
what the effect is, then add optimizations.


One thing that I've been thinking about for a while, is saving (some)
state speculatively.  For example, notify guest a bit before migration
is done, so it can save device state. If guest responds quickly, you
have state that can be restored.  If it doesn't, still migrate, and it
will have to reset on destination.


-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Lan Tianyu <tianyu.lan@intel.com> - 2015-11-24 15:00 +0100
  Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-24 22:30 +0100
    Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-11-25 06:40 +0100
    Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver Lan Tianyu <tianyu.lan@intel.com> - 2015-11-25 07:00 +0100
      Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-25 13:30 +0100
        Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver "Lan, Tianyu" <tianyu.lan@intel.com> - 2015-11-25 17:10 +0100
          Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-25 17:30 +0100
          Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-11-25 17:30 +0100
            Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf  driver "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-25 17:40 +0100
              Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-11-25 18:30 +0100

csiph-web