From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsvBb-0002m4-GF for qemu-devel@nongnu.org; Tue, 17 Dec 2013 08:59:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsvBS-0000F6-Nc for qemu-devel@nongnu.org; Tue, 17 Dec 2013 08:59:47 -0500 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:59132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsvBS-0000F2-Gd for qemu-devel@nongnu.org; Tue, 17 Dec 2013 08:59:38 -0500 Received: by mail-ee0-f43.google.com with SMTP id c13so2894763eek.2 for ; Tue, 17 Dec 2013 05:59:37 -0800 (PST) Date: Tue, 17 Dec 2013 14:59:29 +0100 From: Stefan Hajnoczi Message-ID: <20131217135929.GA2708@stefanha-thinkpad.redhat.com> References: <52AF99D5.4050800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52AF99D5.4050800@redhat.com> Subject: Re: [Qemu-devel] hindsight on qcow2v3 format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: "libvir-list@redhat.com" , "qemu-devel@nongnu.org" On Mon, Dec 16, 2013 at 05:24:53PM -0700, Eric Blake wrote: > Is it worth tweaking docs/specs/qcow2.txt to permanently change the > incompatible_features field to be 4 bytes (76-79) and mandate that bytes > 72-75 always be 0, as a conservative way to prevent other misbehavior of > programs like libvirt 0.10.2 that have code paths that don't correctly > validate for version 2 files? And if we ever really did hit a situation > of having 31 or more incompatible features, I could envision using bit > 31 as an incompatible_feature witness that tells new enough qemu to look > at some other offset for remaining feature bits (thankfully, the > semantics of the incompatible_feature field mean that older qemu that > honors version 3 formats will reject a file with incompatible_feature > bit 31 set), so this is no real loss in the number of potential > incompatible features being added. I don't think qcow2 changes are necessary, just make a libvirt 0.10.x stable release that verifies the qcow2 version. Stefan