On 2019/1/17 下午10:59, Michael S. Tsirkin wrote:
On Thu, Jan 17, 2019 at 05:57:29PM +0800, Jason Wang wrote:
On 2019/1/15 下午10:51, Yongji Xie wrote:
Well, this may work but here're my points:
1) The code want to recover from backed crash by introducing extra space
to store inflight data, but it still depends on the backend to set/get
the inflight state
2) Since the backend could be killed at any time, the backend must have
the ability to recover from the partial inflight state
So it looks to me 1) tends to be self-contradictory and 2) tends to be
recursive. The above lines show how tricky could the code looks like.
Solving this at vhost-user level through at backend is probably wrong.
It's time to consider the support from virtio itself.
I agree that supporting this in virtio level may be better. For
example, resubmitting inflight I/O once DEVICE_NEEDS_RESET is set in
Stefan's proposal. But I still think QEMU should be able to provide
this ability too. Supposed that one vhost-user backend need to support
multiple VMs. We can't enable reconnect ability until all VMs' guest
driver support the new feature. It's limited.
That's the way virtio evolves.
But if QEMU have the
ability to store inflight buffer, the backend could at least have a
chance to support this case.
The problem is, you need a careful designed protocol described somewhere (is
vhost-user.txt a good place for this?). And this work will be (partial)
duplicated for the future support from virtio spec itself.
Maybe backend could have other way to
avoid the tricky code.
I'm not sure, but it was probably not easy.
I see an implementation in libvhost-user.
Do you see an issue there?
I've asked some questions in this thread, it looks like we can still
miss some inflight descriptors.
Thanks
Thanks
Thanks,
