From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyqOv-0007Be-MC for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:33:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyqOt-0007OC-O6 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:33:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyqOt-0007Nq-Eq for qemu-devel@nongnu.org; Mon, 15 Jul 2013 17:33:43 -0400 Message-ID: <51E46AB0.5090708@redhat.com> Date: Mon, 15 Jul 2013 15:33:36 -0600 From: Eric Blake MIME-Version: 1.0 References: <1372931597-28115-1-git-send-email-gaowanlong@cn.fujitsu.com> <1372931597-28115-2-git-send-email-gaowanlong@cn.fujitsu.com> <20130705184115.GP13956@otherpad.lan.raisama.net> <51DB0CD1.7030501@redhat.com> <51E28CC1.2000500@redhat.com> In-Reply-To: <51E28CC1.2000500@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2ECMIXPCCLCEKLXTHWWMA" Subject: Re: [Qemu-devel] [PATCH V4 01/10] NUMA: Support multiple CPU ranges on -numa option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, Eduardo Habkost , qemu-devel@nongnu.org, lcapitulino@redhat.com, bsd@redhat.com, y-goto@jp.fujitsu.com, afaerber@suse.de, Wanlong Gao This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ECMIXPCCLCEKLXTHWWMA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/14/2013 05:34 AM, Paolo Bonzini wrote: >>> Such an incompatible change is not acceptable, as it would break >>> existing configurations. libvirt doesn't specify any suffix and expec= ts >>> it to always mean "MB". >> >> Newer libvirt can be taught to append 'M' when it detects it is talkin= g >> to newer qemu. While you have a point that it is annoying to force >> users to upgrade to a newer libvirt merely because they upgraded qemu,= >> the libvirt point of view is that the following are supported: >> >> old libvirt -> old qemu >> new libvirt -> old qemu >> new libvirt -> new qemu >> >> but that this combination is always best effort and not required to wo= rk: >> >> old libvirt -> new qemu >=20 > I don't think this is the case, unless you're talking of *very* old > libvirt (e.g. pre-QMP). As a counter-example, I can recall a case where a qemu release that used just two digits (was that 1.2?) broke operation under older libvirt that assumed versions would always be three digits; but it definitely occurred after 0.15.x which is the point at which libvirt started favoring QMP. That is, we had a case in Fedora where if you upgraded qemu, you HAD to also update libvirt to be able to keep your guests runni= ng. But yes, the goal of having command line compatibility, so that any application using the same command line it always uses will get the same guest, regardless of a qemu upgrade in the meantime, should be our default mode of operation, even if newer apps should prefer newer (better) command line interfaces. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2ECMIXPCCLCEKLXTHWWMA 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.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR5GqwAAoJEKeha0olJ0NqBvUIAItZKzoeBzHUsSD/u7nkRQvK 1jXxmuczG2IU1MTo/MUdlYEUN/5izyyzIjvvZfHhw9HfK/nbHhKMR/b0nB0wQu13 9XbOApQG+nhf+RLeeywk4Wcb9MC+lNtLl+EAqS0Hgzlz5QWZCUz78MUGzBxWwQHE OK5D39YslZzzGn/76M8NfdBS0rdfxNX+3byDSFnh8JbTE4aT83qptaf1fbYluuU5 7es7cybFduzDEtDpJxavvzGq2nOoFbWxikYmxmGTaDWXqKFfDF8DTsag5orMRc2X 8pOMJktAzdKs0ZCQ6V9uzsB/bBbm3sNLa/oZ75IZXjMFM1MNsbNleu2ItGT0KYM= =1SLi -----END PGP SIGNATURE----- ------enig2ECMIXPCCLCEKLXTHWWMA--