From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Blake Subject: Re: [PATCH v3 2/2] docs: update ivshmem device spec Date: Tue, 09 Sep 2014 13:04:35 -0600 Message-ID: <540F4F43.7020104@redhat.com> References: <1407488118-11245-1-git-send-email-david.marchand@6wind.com> <1407488118-11245-3-git-send-email-david.marchand@6wind.com> <20140808150202.GD13382@stefanha-thinkpad.redhat.com> <53FC2D9C.8020804@6wind.com> <53FC69BE.7010100@redhat.com> <20140828094911.GA26741@stefanha-thinkpad.redhat.com> <540441E4.7080203@6wind.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G" Cc: kvm@vger.kernel.org, claudio.fontana@huawei.com, qemu-devel@nongnu.org, armbru@redhat.com, jani.kokkonen@huawei.com, cam@cs.ualberta.ca To: David Marchand , Stefan Hajnoczi , Paolo Bonzini Return-path: In-Reply-To: <540441E4.7080203@6wind.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/01/2014 03:52 AM, David Marchand wrote: >>> What about upgrading QEMU and ivshmem-server while you have existing >>> guests? You cannot restart ivshmem-server, and the new QEMU would ha= ve >>> to talk to the old ivshmem-server. >> >> Version negotiation also helps avoid confusion if someone combines >> ivshmem-server and QEMU from different origins (e.g. built from source= >> and distro packaged). Don't underestimate the likelihood of this happening. Any long-running process (which an ivshmem-server will be) continues running at the old version, even when a package upgrade installs a new qemu binary; the new binary should still be able to manage connections to the already-running server. Even neater would be a solution where an existing ivshmem-server could re-exec an updated ivshmem-server binary that resulted from a distro upgrade, hand over all state required for the new server to take over from the point managed by the old server, so that you aren't stuck running the old binary forever. But that's a lot trickier to write, so it is not necessary for a first implementation; and if you do that, then you have the reverse situation to worry about (the new server must still accept communication from existing old qemu binaries). Note that the goal here is to support upgrades; it is probably okay if downgrading from a new binary back to an old doesn't work correctly (because the new software was using a feature not present in the old). >> >> It's a safeguard to prevent hard-to-diagnose failures when the system = is >> misconfigured. >> >=20 > Hum, so you want the code to be defensive against mis-use, why not. >=20 > I wanted to keep modifications on ivshmem as little as possible in a > first phase (all the more so as there are potential ivshmem users out > there that I think will be impacted by a protocol change). Existing ivshmem users MUST be aware that they are using something that is not yet polished, and be prepared to make the upgrade to the polished version. It's best to minimize the hassle by making them upgrade exactly once to a fully-robust version, rather than to have them upgrade to a slightly-more robust version only to find out we didn't plan ahead well enough to make further extensions in a back-compatible manner. >=20 > Sending the version as the first "vm_id" with an associated fd to -1 > before sending the real client id should work with existing QEMU client= > code (hw/misc/ivshmem.c). >=20 > Do you have a better idea ? > Is there a best practice in QEMU for "version negotiation" that could > work with ivshmem protocol ? QMP starts off with a mandatory "qmp_capabilities" handshake, although we haven't yet had to define any capabilities where cross-versioned communication differs as a result. Migration is somewhat of an example, except that it is one-directional (we don't have a feedback path), so it is somewhat best effort. The qcow2 v3 file format is an example of declaring features, rather than version numbers, and making decisions about whether a feature is compatible (older clients can safely ignore the bit, without corrupting the image but possibly having worse performance) vs. incompatible (older clients must reject the image, because not handling the feature correctly would corrupt the image). The best handshakes are bi-directional - both sides advertise their version (or better, their features), and a well-defined algorithm for settling on the common subset of advertised features then ensures that the two sides know how to talk to each other, or give a reason for either side to disconnect early because of a missing feature. >=20 > I have a v4 ready with this (and all the pending comments), I will send= > it later unless a better idea is exposed. >=20 >=20 > Thanks. >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUD09DAAoJEKeha0olJ0NqsywH/0DlXqhn2sNAJ0pNA8I2f5kV 7ueDr7IiQZg0PiIZ2OkwWF0nV7pgjefawVIlgW+QM/jgPbL4KgYkedaDznbEs9Cf mjhBgU+0i6978Rt3XxGMpCQ6MMytJ+j2TW7E6mJwyNBlBZ8W83aF8X8QkS0mEeLY dskcWV75u3fdC0aURbc3GANdMA5JPvJtJKZVfL14E5Yd31io/iszDC9lMXjtTSkk 6e9zUh1ZxDBehwKI6GzLj491eWBuYdCBbIaehvHVqbYX6P+9IcgA/y2caBfs+EKW chkJVXgckXFzSXxG1eWCK5n0/UJdvGu/Ugqf9bj4ER1GVK1HU3LaQmSlTqk7qrs= =WOlh -----END PGP SIGNATURE----- --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRQii-0005gQ-TH for qemu-devel@nongnu.org; Tue, 09 Sep 2014 15:04:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRQid-0005D0-Hk for qemu-devel@nongnu.org; Tue, 09 Sep 2014 15:04:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRQid-0005Cv-8p for qemu-devel@nongnu.org; Tue, 09 Sep 2014 15:04:47 -0400 Message-ID: <540F4F43.7020104@redhat.com> Date: Tue, 09 Sep 2014 13:04:35 -0600 From: Eric Blake MIME-Version: 1.0 References: <1407488118-11245-1-git-send-email-david.marchand@6wind.com> <1407488118-11245-3-git-send-email-david.marchand@6wind.com> <20140808150202.GD13382@stefanha-thinkpad.redhat.com> <53FC2D9C.8020804@6wind.com> <53FC69BE.7010100@redhat.com> <20140828094911.GA26741@stefanha-thinkpad.redhat.com> <540441E4.7080203@6wind.com> In-Reply-To: <540441E4.7080203@6wind.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G" Subject: Re: [Qemu-devel] [PATCH v3 2/2] docs: update ivshmem device spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Marchand , Stefan Hajnoczi , Paolo Bonzini Cc: kvm@vger.kernel.org, claudio.fontana@huawei.com, qemu-devel@nongnu.org, armbru@redhat.com, jani.kokkonen@huawei.com, cam@cs.ualberta.ca This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/01/2014 03:52 AM, David Marchand wrote: >>> What about upgrading QEMU and ivshmem-server while you have existing >>> guests? You cannot restart ivshmem-server, and the new QEMU would ha= ve >>> to talk to the old ivshmem-server. >> >> Version negotiation also helps avoid confusion if someone combines >> ivshmem-server and QEMU from different origins (e.g. built from source= >> and distro packaged). Don't underestimate the likelihood of this happening. Any long-running process (which an ivshmem-server will be) continues running at the old version, even when a package upgrade installs a new qemu binary; the new binary should still be able to manage connections to the already-running server. Even neater would be a solution where an existing ivshmem-server could re-exec an updated ivshmem-server binary that resulted from a distro upgrade, hand over all state required for the new server to take over from the point managed by the old server, so that you aren't stuck running the old binary forever. But that's a lot trickier to write, so it is not necessary for a first implementation; and if you do that, then you have the reverse situation to worry about (the new server must still accept communication from existing old qemu binaries). Note that the goal here is to support upgrades; it is probably okay if downgrading from a new binary back to an old doesn't work correctly (because the new software was using a feature not present in the old). >> >> It's a safeguard to prevent hard-to-diagnose failures when the system = is >> misconfigured. >> >=20 > Hum, so you want the code to be defensive against mis-use, why not. >=20 > I wanted to keep modifications on ivshmem as little as possible in a > first phase (all the more so as there are potential ivshmem users out > there that I think will be impacted by a protocol change). Existing ivshmem users MUST be aware that they are using something that is not yet polished, and be prepared to make the upgrade to the polished version. It's best to minimize the hassle by making them upgrade exactly once to a fully-robust version, rather than to have them upgrade to a slightly-more robust version only to find out we didn't plan ahead well enough to make further extensions in a back-compatible manner. >=20 > Sending the version as the first "vm_id" with an associated fd to -1 > before sending the real client id should work with existing QEMU client= > code (hw/misc/ivshmem.c). >=20 > Do you have a better idea ? > Is there a best practice in QEMU for "version negotiation" that could > work with ivshmem protocol ? QMP starts off with a mandatory "qmp_capabilities" handshake, although we haven't yet had to define any capabilities where cross-versioned communication differs as a result. Migration is somewhat of an example, except that it is one-directional (we don't have a feedback path), so it is somewhat best effort. The qcow2 v3 file format is an example of declaring features, rather than version numbers, and making decisions about whether a feature is compatible (older clients can safely ignore the bit, without corrupting the image but possibly having worse performance) vs. incompatible (older clients must reject the image, because not handling the feature correctly would corrupt the image). The best handshakes are bi-directional - both sides advertise their version (or better, their features), and a well-defined algorithm for settling on the common subset of advertised features then ensures that the two sides know how to talk to each other, or give a reason for either side to disconnect early because of a missing feature. >=20 > I have a v4 ready with this (and all the pending comments), I will send= > it later unless a better idea is exposed. >=20 >=20 > Thanks. >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUD09DAAoJEKeha0olJ0NqsywH/0DlXqhn2sNAJ0pNA8I2f5kV 7ueDr7IiQZg0PiIZ2OkwWF0nV7pgjefawVIlgW+QM/jgPbL4KgYkedaDznbEs9Cf mjhBgU+0i6978Rt3XxGMpCQ6MMytJ+j2TW7E6mJwyNBlBZ8W83aF8X8QkS0mEeLY dskcWV75u3fdC0aURbc3GANdMA5JPvJtJKZVfL14E5Yd31io/iszDC9lMXjtTSkk 6e9zUh1ZxDBehwKI6GzLj491eWBuYdCBbIaehvHVqbYX6P+9IcgA/y2caBfs+EKW chkJVXgckXFzSXxG1eWCK5n0/UJdvGu/Ugqf9bj4ER1GVK1HU3LaQmSlTqk7qrs= =WOlh -----END PGP SIGNATURE----- --X6sAGINEcp6iQ5alNt7ExrW1XMNIrmD7G--