On Mon, Jan 14, 2019 at 06:55:40PM +0800, Yongji Xie wrote: > On Mon, 14 Jan 2019 at 18:22, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > On Sat, Jan 12, 2019 at 12:50:12PM +0800, Yongji Xie wrote: > > > On Fri, 11 Jan 2019 at 23:53, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > > > > > > > On Thu, Jan 10, 2019 at 06:59:27PM +0800, Yongji Xie wrote: > > > > > On Thu, 10 Jan 2019 at 18:25, Stefan Hajnoczi <stefa...@gmail.com> > > > > > wrote: > > > > > > > > > > > > On Wed, Jan 09, 2019 at 07:27:21PM +0800, elohi...@gmail.com wrote: > > > > I'm concerned that this approach to device recovery is invasive and hard > > > > to test. Instead I would use VIRTIO's Device Status Field > > > > DEVICE_NEEDS_RESET bit to tell the guest driver that a reset is > > > > necessary. This is more disruptive - drivers either have to resubmit or > > > > fail I/O with EIO - but it's also simple and more likely to work > > > > correctly (it only needs to be implemented correctly in the guest > > > > driver, not in the many available vhost-user backend implementations). > > > > > > > > > > So you mean adding one way to notify guest to resubmit inflight I/O. I > > > think it's a good idea. But would it be more flexible to implement > > > this in backend. We can support old guest. And it will be easy to fix > > > bug or add feature. > > > > There are trade-offs with either approach. In the long run I think it's > > beneficial minimize non-trivial logic in vhost-user backends. There > > will be more vhost-user backend implementations and therefore more bugs > > if we put the logic into the backend. This is why I think a simple > > mechanism for marking the device as needing a reset will be more > > reliable and less trouble. > > > > I agree. So is it possible to implement both? In the long run, > updating guest driver to support this is better. And at that time, the > logic in backend can be only used to support legacy guest driver.
Yes, in theory both approaches could be available. Stefan
signature.asc
Description: PGP signature
