From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZf3l-0007gm-3I for qemu-devel@nongnu.org; Wed, 19 Dec 2018 11:51:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZf3g-0002Kf-BD for qemu-devel@nongnu.org; Wed, 19 Dec 2018 11:51:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35888) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gZf3e-0002F0-2f for qemu-devel@nongnu.org; Wed, 19 Dec 2018 11:50:55 -0500 Date: Wed, 19 Dec 2018 11:50:38 -0500 From: "Michael S. Tsirkin" Message-ID: <20181219114920-mutt-send-email-mst@kernel.org> References: <20181218100002.11219-1-xieyongji@baidu.com> <20181218100002.11219-2-xieyongji@baidu.com> <20181218152520.GB4807@redhat.com> <20181218104351-mutt-send-email-mst@kernel.org> <20181218160919.GD4807@redhat.com> <20181219105418-mutt-send-email-mst@kernel.org> <20181219160102.GL20465@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20181219160102.GL20465@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 for-4.0 1/7] chardev: Add disconnected option for chardev socket List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= Cc: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , elohimes@gmail.com, zhangyu31@baidu.com, xieyongji@baidu.com, Jason Wang , qemu-devel , lilin24@baidu.com, Yury Kotov , "Coquelin, Maxime" , chaiwen@baidu.com, nixun@baidu.com On Wed, Dec 19, 2018 at 04:01:02PM +0000, Daniel P. Berrang=E9 wrote: > On Wed, Dec 19, 2018 at 10:55:09AM -0500, Michael S. Tsirkin wrote: > > On Tue, Dec 18, 2018 at 04:09:19PM +0000, Daniel P. Berrang=E9 wrote: > > > On Tue, Dec 18, 2018 at 11:02:46AM -0500, Michael S. Tsirkin wrote: > > > > On Tue, Dec 18, 2018 at 03:25:20PM +0000, Daniel P. Berrang=E9 wr= ote: > > > > > On Tue, Dec 18, 2018 at 04:24:26PM +0400, Marc-Andr=E9 Lureau w= rote: > > > > > > Hi > > > > > >=20 > > > > > > On Tue, Dec 18, 2018 at 2:01 PM wrote: > > > > > > > > > > > > > > From: Xie Yongji > > > > > > > > > > > > > > New option "disconnected" is added to init the chardev sock= et > > > > > > > in disconnected state. Then we can use qemu_chr_fe_wait_con= nected() > > > > > > > to connect when necessary. Now it would be used for unix do= main > > > > > > > socket of vhost-user-blk device to support reconnect. > > > > > >=20 > > > > > > What difference does that make if you wait for connection in > > > > > > qemu_chr_fe_wait_connected(), or during chardev setup? > > > > > >=20 > > > > > > "disconnected" is misleading, would it be possible to reuse > > > > > > "wait/nowait" instead? > > > > >=20 > > > > > Currently we default to doing a blocking connect in foreground, > > > > > except if reconnect is non-zero, in which case we do a connect > > > > > async in the background. This "disconnected" proposal effective= ly > > > > > does a blocking connect, but delayed to later in startup. > > > > >=20 > > > > > IOW, this could already be achieved if "reconnect" were set to > > > > > non-zero. If the usage doesn't want reconnect though, I tend > > > > > to agree that we should use the exisiting wait/nowait options > > > > > to let it be controlled. I don't see that this "disconnected" > > > > > option gives a compelling benefit over using wait/nowait. > > > >=20 > > > > So the tricky thing is that we can not expose the > > > > device to guest until we get a connection and can query > > > > it for the first time. After that is completed, > > > > we can reasonably support disconnected operation at least for net= . > > >=20 > > > The device code would still use qemu_chr_fe_wait_connected() in my= proposal, > > > so that its no different to the situation with the proposed "discon= nected" > > > flag. > > >=20 > > > Regards, > > > Daniel > >=20 > > I guess so, but wouldn't it be confusing to users that one says > > "nowait" and qemu still waits for a connection and does not > > run the VM? That's different from how nowait behaves normally. >=20 > Well "nowait" is only referring to the chardev behaviour which is > still an accurate description. man page seems to say nowait specifies that QEMU should not block waiting for a clie= nt to connect to a listening socket. if we do wait for a client to connect then how is it accurate? > The fact that the network then waits during startup is a seperate > matter. We don't define chardev semantics in terms of possible > users as there are many distinct users of chardevs in QEMU. >=20 > Regards, > Daniel > --=20 > |: https://berrange.com -o- https://www.flickr.com/photos/dberr= ange :| > |: https://libvirt.org -o- https://fstop138.berrange= .com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberr= ange :|