From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm7Pc-0002xU-Hs for qemu-devel@nongnu.org; Tue, 03 Jul 2012 14:01:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sm7PW-0002LM-66 for qemu-devel@nongnu.org; Tue, 03 Jul 2012 14:01:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm7PV-0002Ky-TU for qemu-devel@nongnu.org; Tue, 03 Jul 2012 14:01:14 -0400 Message-ID: <4FF33349.10404@redhat.com> Date: Tue, 03 Jul 2012 12:00:41 -0600 From: Eric Blake MIME-Version: 1.0 References: <1340390174-7493-1-git-send-email-coreyb@linux.vnet.ibm.com> <20120626091004.GA14451@redhat.com> <4FE9A0F0.2050809@redhat.com> <20120626175045.2c7011b3@doriath.home> <4FEA37A9.10707@linux.vnet.ibm.com> <4FEA3D9C.8080205@redhat.com> <4FF21A67.8010100@linux.vnet.ibm.com> <4FF31265.1000308@linux.vnet.ibm.com> <4FF316C9.5020100@redhat.com> <4FF31CFD.7030508@linux.vnet.ibm.com> <4FF325C8.4060401@redhat.com> <4FF33004.5030909@linux.vnet.ibm.com> In-Reply-To: <4FF33004.5030909@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigAF56D051E0AEE1D79C618D08" Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: Kevin Wolf , aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAF56D051E0AEE1D79C618D08 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/03/2012 11:46 AM, Corey Bryant wrote: >=20 > Yes, I think adding a +1 to the refcount for the monitor makes sense. >=20 > I'm a bit unsure how to increment the refcount when a monitor reconnect= s > though. Maybe it is as simple as adding a +1 to each fd's refcount whe= n > the next QMP monitor connects. Or maybe delay a +1 until after a 'query-fds' - it is not until the monitor has reconnected and learned what fds it should be aware of that incrementing the refcount again makes sense. But that would mean making 'query-fds' track whether this is the first call since the monitor reconnected, as it shouldn't normally increase refcounts. The other alternative is that the monitor never re-increments a refcount. Once a monitor disconnects, that fd is lost to the monitor, and a reconnected monitor must pass in a new fd to be re-associated with the fdset. In other words, the monitor's use of an fd is a one-way operation, starting life in use but ending at the first disconnect or remove-fd. >> 1. client calls 'add-fd', qemu is now tracking fd=3D4 with refcount 1,= in >> use by monitor, as member of fdset1 >> 2. client calls 'device-add' with /dev/fdset/1 as the backing filename= , >> so qemu_open() increments the refcount to 2 >> 3. client crashes, so all tracked fds are visited; fd=3D4 had not yet = been >> passed to 'remove-fd', so qemu decrements refcount to 1, but leaves fd= =3D4 >> open because it is still in use by the block device >> 4. client re-establishes QMP connection, and 'query-fds' lets client >> learn about fd=3D4 still being open as part of fdset1, but also inform= s >> client that fd is not in use by the monitor >=20 > And in step 4 the QMP connection will increment the refcount +1 for all= > fds that persisted through the QMP disconnect. (?) I'm not sure we need the refcount increment on reconnect. 'query-fds' should provide enough information for the new monitor to know what fdsets are still in use by qemu, even though they are no longer available to 'remove-fd' from the monitor, and if the monitor is worried about keeping the fd set alive it can call 'add-fd' to again associate a new fd with the set. The lifetime of a set is thus as long as any of its associated fds have a non-zero refcount. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigAF56D051E0AEE1D79C618D08 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP8zNKAAoJEKeha0olJ0NqMQ8IAIvHR4gn0s+sv5jjw/uh3HXE X+eDLB5MM1fYnjM29K4chzEXlt1bMfiHgFlfU5aSE9SUG6m9cm7t8pFNbZs/L7JG w1M0tLpPGXl7JKStC2vZTylN9qAs5IuTQMD0aG/p02r/ix/jLvUb9gcWgHcvp6nL LSPoMCjJ9kG2Rcq6PYrK8PKxNM1bjXW3xeYS1Mz6EYl99OhFnOW9rm5WO1aLOsZX 1zAjBoA8lqYyeb9aZJRmGJmGsdxhEYhwAtWLBInn3nxCY3IUoP8bhiWArjZxelvD 832Z9FANV6JORiivGwCF8RKda9b2dKl6EN1OOC7UfG9KFArx2athzOHCKQhx2OA= =XokS -----END PGP SIGNATURE----- --------------enigAF56D051E0AEE1D79C618D08--