[Qemu-devel] chardev: vhost-user: reconnect issue when QEMU as server

* [Qemu-devel] chardev: vhost-user: reconnect issue when QEMU as server
@ 2016-03-09 13:29 Yuanhan Liu
  2016-03-09 15:04 ` Marc-André Lureau
  0 siblings, 1 reply; 3+ messages in thread
From: Yuanhan Liu @ 2016-03-09 13:29 UTC (permalink / raw)
  To: Paolo Bonzini, Michael S. Tsirkin; +Cc: qemu-devel

Hi,

Currently, the typical usage of vhost-user is QEMU as the client, while
the backend (say DPDK vhost-user) be the server. There is a major drawback:
the restart of the backend (say, upgrade) needs restart the QEMU.

The obvious solution would be let QEMU be the server and the backend
be the client. I did a quick try before, and it would work as expected,
if it's the first time the client tries to connect the server. However,
it would not, if it's the second (or later) times, say a client restart.

Per my understanding so far, there are two factors caused such issue:

1) QEMU socket char dev is designed as one server accepts one
   client only. A server will not accept another client unless
   there is no connection established, or the connection is
   disconnected.

2) For vhost-user case, QEMU serves as the initiator, that sends
   vhost-user messages on his own. In another word, QEMU will
   not poll the socket fd, unlike DPDK vhost-user. That is to say
   QEMU has no idea to know when the connection is disconnected.
   According to 1), QEMU will not be able to accept the second
   connect from DPDK, when DPDK vhost restarts.

In summary, we need figure out a way to detect the disconnect at QEMU.
I came up with a solution that might work: we poll the socket fd, and
peek (instead of read) the data. Peek would fail if a connection is
disconnected. I had a quick hack, unluckily, it didn't work as expected.
I'm thinking I might have missed something.

I could spend more time to dig it. But before that, I want to know
how you guys think about it?  Does that proposal makes sense to you?
Or, any better ideas?

Thanks.

	--yliu

^ permalink raw reply	[flat|nested] 3+ messages in thread