> On 22 Aug 2023, at 6:17 PM, Raphael Norwitz
> wrote:
>
>
>
>> On Aug 22, 2023, at 12:49 AM, Li Feng wrote:
>>
>>
>>
>>> On 22 Aug 2023, at 8:38 AM, Raphael Norwitz
>>> wrote:
>>>
On Aug 17, 2023, at 2:40 AM, Li Feng wrote:
> 2023年8月14日 下午8:11，Raphael Norw
> On Aug 22, 2023, at 12:49 AM, Li Feng wrote:
>
>
>
>> On 22 Aug 2023, at 8:38 AM, Raphael Norwitz
>> wrote:
>>
>>>
>>> On Aug 17, 2023, at 2:40 AM, Li Feng wrote:
>>>
>>>
2023年8月14日 下午8:11，Raphael Norwitz 写道：
Why can’t we rather fix this by adding a “event_cb” param
On 22 Aug 2023, at 8:38 AM, Raphael Norwitz
wrote:
On Aug 17, 2023, at 2:40 AM, Li Feng wrote:
2023年8月14日 下午8:11，Raphael Norwitz 写道：
Why can’t we rather fix this by adding a “event_cb” param to
vhost_user_async_close and then call qemu_chr_fe_set_handlers in
vhost_user_async_close_bh()?
Ev
> On Aug 17, 2023, at 2:40 AM, Li Feng wrote:
>
>
>> 2023年8月14日 下午8:11，Raphael Norwitz 写道：
>>
>> Why can’t we rather fix this by adding a “event_cb” param to
>> vhost_user_async_close and then call qemu_chr_fe_set_handlers in
>> vhost_user_async_close_bh()?
>>
>> Even if calling vhost_dev_
> 2023年8月14日 下午8:11，Raphael Norwitz 写道：
>
> Why can’t we rather fix this by adding a “event_cb” param to
> vhost_user_async_close and then call qemu_chr_fe_set_handlers in
> vhost_user_async_close_bh()?
>
> Even if calling vhost_dev_cleanup() twice is safe today I worry future
> changes may
Why can’t we rather fix this by adding a “event_cb” param to
vhost_user_async_close and then call qemu_chr_fe_set_handlers in
vhost_user_async_close_bh()?
Even if calling vhost_dev_cleanup() twice is safe today I worry future changes
may easily stumble over the reconnect case and introduce cras
When the vhost-user is reconnecting to the backend, and if the vhost-user fails
at the get_features in vhost_dev_init(), then the reconnect will fail
and it will not be retriggered forever.
The reason is:
When the vhost-user fail at get_features, the vhost_dev_cleanup will be called
immediately.
