From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39606 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxeK4-0006bG-9d for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:46:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxeK2-0007B6-Sx for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:46:28 -0500 Received: from goliath.siemens.de ([192.35.17.28]:34278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxeK2-0007AB-J3 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:46:26 -0500 Message-ID: <4D78BA01.6050409@siemens.com> Date: Thu, 10 Mar 2011 12:46:09 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20110310094726.GB14805@redhat.com> <4D78B5BB.5020408@siemens.com> In-Reply-To: <4D78B5BB.5020408@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: emulation of system flash List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity , Jordan Justen On 2011-03-10 12:27, Jan Kiszka wrote: > On 2011-03-10 10:47, Gleb Natapov wrote: >> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote: >>> Hi all, >>> >>> I have documented a simple flash-like device which I think could be >>> useful for qemu/kvm in some cases. (Particularly for allowing >>> persistent UEFI non-volatile variables.) >>> >>> http://wiki.qemu.org/Features/System_Flash >>> >>> Let me know if you have any suggestions or concerns. >>> >> >> Two things. First You suggest to replace -bios with -flash. This will >> make firmware upgrade painful process that will have to be performed >> from inside the guest since the same flash image will contain both >> firmware and whatever data was stored on a flash which presumably you >> want to reuse after upgrading a firmware. My suggestion is to extend >> -bios option like this: >> >> -bios bios.bin,flash=flash.bin,flash_base=addr >> >> flash.bin will be mapped at address flash_base, or, if flash_base is not >> present, just below bios.bin. > > ...or define -flash in a way that allows mapping the bios image as an > overlay to the otherwise guest-managed flash image. Better define flash chips as qdev devices and make the attributes qdev properties: -device flash,image=...,base=...,overlay=...,overlay_start=... Images should be addressed by block device IDs and created via '-drive' (likely requires a new interface type 'flash'). That way you could define the bios overlay as "snapshot" so that the guest could happily corrupt it, but restarting the VM would pick up a well-defined version again. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux