On 2015/06/24 14:57, Michael S. Tsirkin wrote: >>>>>> Also, if QEMU or the backend is closed unexpectedly, there is no way to >>>>>> recover without restarting both applications. >>>>> This was previously discussed: >>>>> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg00585.html >>>>> It doesn't look like any of the issues have been addressed. >>>>> >>>>> In my opinion, the right way to handle this requires >>>>> guest cooperation. For example, we can extend virtio 1 to allow a >>>>> single queue to reset. >>>>> >>>>> We then can do something like the following: >>>>> - hypervisor detects queue backend disconnect. >>>>> - hypervisor sets flag and notifies guest >>>>> - guest resets queue, optionally discarding queued packets >>>>> - hypervisor detects (or requests if it's a client), backend reconnect >>>>> - hypervisor detects guest queue reset >>>>> - hypervisor notifies guests about backend reconnect >>>>> - hypervisor sends hypervisor device state (e.g. queue addresses and >>>>> indices) to backend >>>>> >>>>> Reconnect isn't robust without such an extension. >>>> I appreciate your all comments. It's truly helpful. >>>> Do you have any plans to support such queue reset features in virtio spec? >>> Maybe, but I don't have the time to work on this :( >>> You are welcome to contribute this. >> To do that, I need to talk around my boss to join OASIS :'( > That's not true at all. Non members can submit feedback. > You do need permission from your employer, but > no need to join and pay fees if you don't want to. > See > https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio > for the details.
Thanks so much for correcting. >> Probably it's not so easy, so I will just wait, if we need to change >> spec itself. > The QEMU patch that allows handling backend disconnect similar to > disk errors can be implemented without guest/spec changes > let me know if you need more explanation. Could you please describe it more? I want to try to implement it. Regards, Tetsuya
