From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlj0r-00071u-Eb for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:35:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vlj0l-0000h3-BW for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:34:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlj0l-0000gx-3j for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:34:51 -0500 Message-ID: <52962D2F.7090900@redhat.com> Date: Wed, 27 Nov 2013 18:34:39 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1385072461-31317-1-git-send-email-lersek@redhat.com> <87iovkvd8t.fsf@blackfin.pond.sub.org> <528FA2AB.2040806@redhat.com> <871u244ic6.fsf@blackfin.pond.sub.org> <5293A8CF.1000602@redhat.com> <87y54bgx1e.fsf@blackfin.pond.sub.org> <5294A301.9050101@redhat.com> <87iove7xzm.fsf@blackfin.pond.sub.org> <5295FB20.1000007@redhat.com> <8761rd52fc.fsf@blackfin.pond.sub.org> <52960D2C.4020103@redhat.com> <87zjopwyhr.fsf@blackfin.pond.sub.org> In-Reply-To: <87zjopwyhr.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "edk2-devel@lists.sourceforge.net" , Jordan Justen , qemu-devel , Cole Robinson On 11/27/13 18:22, Markus Armbruster wrote: > Perhaps the proper way to back partially writable flash contents isn't > splitting it into two devices, but backing a single device with a COW. > The backing file has initial contents (say BIOS image), the delta may > have additional contents (say non-volatile configuration), and picks up > whatever the device model permits to be written to the flash. Kevin brought this up before. The problem is that this prevents you from upgrading the read-only part in O(1). (Unless of course you're willing to make the backing file raw *and* to poke directly in it when you upgrade the bios binary part. Theoretically you could do this, because the divide between the varstore and the binary part at 128KB falls at a qcow2 block boundary (supposing a 64K qcow2 block size), but in practice this is a horrible idea :)) Let's not veer off into architecting a new star destroyer. I think I have plenty ammo from your great notes thus far that I can hack up a v2 with :) Thanks Laszlo