[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devic
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices |
Date: |
Fri, 29 May 2020 12:12:54 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
* Alex Williamson (alex.williamson@redhat.com) wrote:
> On Thu, 28 May 2020 04:01:02 -0400
> Yan Zhao <yan.y.zhao@intel.com> wrote:
>
> > > > > This is my understanding of the protocol as well, when the device is
> > > > > running, pending_bytes might drop to zero if no internal state has
> > > > > changed and may be non-zero on the next iteration due to device
> > > > > activity. When the device is not running, pending_bytes reporting
> > > > > zero
> > > > > indicates the device is done, there is no further state to transmit.
> > > > > Does that meet your need/expectation?
> > > > >
> > > > (1) on one side, as in vfio_save_pending(),
> > > > vfio_save_pending()
> > > > {
> > > > ...
> > > > ret = vfio_update_pending(vbasedev);
> > > > ...
> > > > *res_precopy_only += migration->pending_bytes;
> > > > ...
> > > > }
> > > > the pending_bytes tells migration thread how much data is still hold in
> > > > device side.
> > > > the device data includes
> > > > device internal data + running device dirty data + device state.
> > > >
> > > > so the pending_bytes should include device state as well, right?
> > > > if so, the pending_bytes should never reach 0 if there's any device
> > > > state to be sent after device is stopped.
> > >
> > > I hadn't expected the pending-bytes to include a fixed offset for device
> > > state (If you mean a few registers etc) - I'd expect pending to drop
> > > possibly to zero; the heuristic as to when to switch from iteration to
> > > stop, is based on the total pending across all iterated devices; so it's
> > > got to be allowed to drop otherwise you'll never transition to stop.
> > >
> > ok. got it.
>
> Yeah, as I understand it, a device is not required to participate in
> reporting data available while (_SAVING | _RUNNING), there will always
> be an iteration while the device is !_RUNNING. Therefore if you have
> fixed device state that you're always going to send, it should only be
> sent once when called during !_RUNNING. The iterative phase should be
> used where you have a good chance to avoid re-sending data at the
> stop-and-copy phase. Thanks,
Right.
Dave
> Alex
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, (continued)
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Yan Zhao, 2020/05/25
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Kirti Wankhede, 2020/05/25
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Alex Williamson, 2020/05/26
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Yan Zhao, 2020/05/27
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Dr. David Alan Gilbert, 2020/05/27
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Yan Zhao, 2020/05/28
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Alex Williamson, 2020/05/28
- Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices,
Dr. David Alan Gilbert <=
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Alex Williamson, 2020/05/28
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Yan Zhao, 2020/05/29
Re: [PATCH Kernel v22 0/8] Add UAPIs to support migration for VFIO devices, Kirti Wankhede, 2020/05/29