From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41677 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxmAK-0002bD-1O for qemu-devel@nongnu.org; Thu, 10 Mar 2011 15:08:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxmAH-00084B-Ag for qemu-devel@nongnu.org; Thu, 10 Mar 2011 15:08:55 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:50319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxmAH-000843-81 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 15:08:53 -0500 Received: by qyk36 with SMTP id 36so6334677qyk.4 for ; Thu, 10 Mar 2011 12:08:52 -0800 (PST) MIME-Version: 1.0 Sender: xvilka@gmail.com In-Reply-To: References: <20110310094726.GB14805@redhat.com> <20110310191246.GA18052@redhat.com> Date: Thu, 10 Mar 2011 23:08:51 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: RFC: emulation of system flash From: =?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reply-To: anton.kochkov@gmail.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Gleb Natapov , Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity As I'm working on bootrom loading support for omap/arm platform, I'm have suggestion about something more universal than -bios (and even -flash) option. Because Flash can be NOR, can be NAND, but on-chip memory is not flash memory. So may be something like -rom option? Best regards, Anton Kochkov. On Thu, Mar 10, 2011 at 22:50, Jordan Justen wrote: > On Thu, Mar 10, 2011 at 11:12, Gleb Natapov wrote: >> On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote: >>> Yes, this definitely could add firmware upgrade issues, but I thought >>> this could be the responsibility of the firmware itself. =C2=A0For exam= ple, >>> OVMF could have an outside of VM tool to merge new releases, or it >>> could have an inside of VM firmware update process. >> Why require another tool if can do without? I don't see any advantages >> in storing firmware code and its non-volatile storage in the same image, >> but I do see disadvantages. > > I agree. =C2=A0The implications of a firmware image getting out of sync > with qemu were a bit of a concern to me. =C2=A0But, having both -bios + > -flash just below -bios was starting to seem a bit complicated. > > And, I guess as a firmware developer, I thought it might be > interesting to consider enabling a firmware update process within the > VM. :) > > How about? > 1) Pure rom: > -bios bios.bin > 2) Rom + flash below rom: > -bios bios.bin,flash=3Dflash.bin > 3) Pure flash: > -bios flash=3Dflash.bin > > Or, with a separate new -flash option: > 1) Pure rom: > -bios bios.bin > or no -bios or -flash parameters > 2) Rom + flash below rom: > -bios bios.bin -flash flash.bin > 3) Pure flash: > -flash flash.bin > >> It is not even about performance (which will be very bad for 1MB). KVM >> can't run code from MMIO region, so the part that contains firmware >> has to be memory. > > Hmm. =C2=A0That's good to know. :) > > So, perhaps this feature should build upon the other feature you and > Jan are discussing. =C2=A0When will it become available? > > Thanks, > > -Jordan > >