On Mon, Apr 17, 2023 at 9:46 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Mon, 17 Apr 2023 at 15:12, Eugenio Perez Martin <epere...@redhat.com> > wrote: > > > > On Mon, Apr 17, 2023 at 9:08 PM Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > > > On Mon, 17 Apr 2023 at 14:56, Eugenio Perez Martin <epere...@redhat.com> > > > wrote: > > > > > > > > On Mon, Apr 17, 2023 at 5:18 PM Stefan Hajnoczi <stefa...@redhat.com> > > > > wrote: > > > > > > > > > > On Fri, Apr 14, 2023 at 05:17:02PM +0200, Eugenio Perez Martin wrote: > > > > > > On Thu, Apr 13, 2023 at 7:55 PM Hanna Czenczek <hre...@redhat.com> > > > > > > wrote: > > > > > > > > > > > > > > On 13.04.23 13:38, Stefan Hajnoczi wrote: > > > > > > > > On Thu, 13 Apr 2023 at 05:24, Hanna Czenczek > > > > > > > > <hre...@redhat.com> wrote: > > > > > > > >> On 12.04.23 23:06, Stefan Hajnoczi wrote: > > > > > > > >>> On Tue, Apr 11, 2023 at 05:05:13PM +0200, Hanna Czenczek > > > > > > > >>> wrote: > > > > > > > Basically, what I’m hearing is that I need to implement a > > > > > > > different > > > > > > > feature that has no practical impact right now, and also fix bugs > > > > > > > around > > > > > > > it along the way... > > > > > > > > > > > > > > > > > > > To fix this properly requires iterative device migration in qemu as > > > > > > far as I know, instead of using VMStates [1]. This way the state is > > > > > > requested to virtiofsd before the device reset. > > > > > > > > > > I don't follow. Many devices are fine with non-iterative migration. > > > > > They > > > > > shouldn't be forced to do iterative migration. > > > > > > > > > > > > > Sorry I think I didn't express myself well. I didn't mean to force > > > > virtiofsd to support the iterative migration, but to use the device > > > > iterative migration API in QEMU to send the needed commands before > > > > vhost_dev_stop. In that regard, the device or the vhost-user commands > > > > would not require changes. > > > > > > > > I think it is convenient in the long run for virtiofsd, as if the > > > > state grows so much that it's not feasible to fetch it in one shot > > > > there is no need to make changes in the qemu migration protocol. I > > > > think it is not unlikely in virtiofs, but maybe I'm missing something > > > > obvious and it's state will never grow. > > > > > > I don't understand. vCPUs are still running at that point and the > > > device state could change. It's not safe to save the full device state > > > until vCPUs have stopped (after vhost_dev_stop). > > > > > > > I think the vCPU is already stopped at save_live_complete_precopy > > callback. Maybe my understanding is wrong? > > Agreed, vCPUs are stopped in save_live_complete_precopy(). However, > you wrote "use the device iterative migration API in QEMU to send the > needed commands before vhost_dev_stop". save_live_complete_precopy() > runs after vhost_dev_stop() so it doesn't seem to solve the problem. >
You're right, and it actually makes the most sense. So I guess this converges with the other thread, let's follow the discussion there. Thanks!
