From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48903 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pxe2Q-0003xI-5i for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:28:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pxe2O-0003Wg-LS for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:28:13 -0500 Received: from goliath.siemens.de ([192.35.17.28]:27313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pxe2O-0003Vp-Cj for qemu-devel@nongnu.org; Thu, 10 Mar 2011 06:28:12 -0500 Message-ID: <4D78B5BB.5020408@siemens.com> Date: Thu, 10 Mar 2011 12:27:55 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20110310094726.GB14805@redhat.com> In-Reply-To: <20110310094726.GB14805@redhat.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 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. > > Second. I asked how flash is programmed because interfaces like CFI > where you write into flash memory address range to issue commands cannot > be emulated efficiently in KVM. KVM supports either regular memory slots > or IO memory, but in your proposal the same memory behaves as IO on > write and regular memory on read. Better idea would be to present > non-volatile flash as ISA virtio device. Should be simple to implement. Why not enhancing KVM memory slots to support direct read access while writes are trapped and forwarded to a user space device model? Virtio means that you have to patch the guest (which might be something else than flexible Linux...). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux